BIO_meth_get_write function

  1. @RecordUse.new()
  2. @Native<Pointer<NativeFunction<Int Function(Pointer<BIO>, Pointer<Char>, Int)>> Function(Pointer<BIO_METHOD> method)>(ffi.Pointer<BIO>, ffi.Pointer<ffi.Char>, ffi.Int)>> Function(ffi.Pointer<BIO_METHOD>)>(symbol: 'bssl_dart_BIO_meth_get_write')
Pointer<NativeFunction<Int Function(Pointer<BIO>, Pointer<Char>, Int)>> BIO_meth_get_write(
  1. Pointer<BIO_METHOD> method
)

The following functions return function pointers, possibly NULL, which are compatible with the corresponding |BIO_meth_set_*| function. |method| must be |BIO_s_socket| or the program will abort.

Using these functions is inherently unsafe and fragile. It is not possible to use them in a future-proof way. See https://github.com/openssl/openssl/issues/26047 for details. BoringSSL implements them solely for compatibility with Folly and older versions of PostgreSQL. To work around the future-proofing problems, the return values may diverge from the true implementation of |BIO_s_socket|.

Caller should not use these functions. They are not necessary to define custom |BIO_METHOD|s. Instead, callers should either:

  • Define a custom |BIO_METHOD| that owns a socket |BIO| somewhere in the custom data. See |BIO_set_data|.

  • Define a custom |BIO_METHOD| that wraps a socket |BIO| as a filter. See |BIO_push| and |BIO_next|.

  • Define a custom |BIO_METHOD| without |BIO_s_socket| at all. If not using the built-in read or write functions, |BIO_s_socket| only provides a no-op |BIO_CTRL_FLUSH| implementation. This can be implemented by the caller.

Implementation

@meta.RecordUse()
@ffi.Native<
  ffi.Pointer<
    ffi.NativeFunction<
      ffi.Int Function(ffi.Pointer<BIO>, ffi.Pointer<ffi.Char>, ffi.Int)
    >
  >
  Function(ffi.Pointer<BIO_METHOD>)
>(symbol: 'bssl_dart_BIO_meth_get_write')
external ffi.Pointer<
  ffi.NativeFunction<
    ffi.Int Function(ffi.Pointer<BIO>, ffi.Pointer<ffi.Char>, ffi.Int)
  >
>
BIO_meth_get_write(
  ffi.Pointer<BIO_METHOD> method,
);