I recently attempted to convert libopusfile to the new 1.1 API changes
(in response to this Debian bug report:
<https://bugs.debian.org/828480>, if you want to see what broke).
I realize that this late in the release cycle, people are unlikely to
want to make additional backwards-incompatible changes, but you may find
some of this useful, nonetheless. Feel free to disregard it, also, as it
is just one developer's opinion.
1) There is no accessor for the "num" field in the BIO struct.
This is typically used to store a file descriptor or similar value. As
can be seen by its explicit access in BIO_dup_chain(), there may be
legitimate reasons to get at its value, even if you are not writing your
own new BIO implementation.
2) The API documentation for BIO_meth_new() says that "type" should be a
unique integer, but provides no way to ensure this is true.
Particularly, when using this from a library, I have no way to ensure
that some number I choose here does not conflict with that chosen by
some other library in the same application, or with the application
itself. Furthermore, the values used by OpenSSL for its own internal BIO
implementations appear to have some structure which the code relies on,
but which is not documented. Not really having any way to do what the
documentation asks for, I've simply chosen to pass in BIO_TYPE_NULL, and
live with the fact that anything that relies on this being unique (not
much, that I can tell) will not work correctly.
3) I'm not sure the conversion of BIO_METHOD to an opaque struct is
really a good idea. In prior versions of the library, anyone wanting to
make their own BIO implementation would typically have a static table
(which could not be const because the API did not take const pointers).
OpenSSL itself does this for all of its BIO implementations (which are
now fortunately const), and any difficulties you might see there in
converting to use the new API apply equally well to external
implementations.
If extensibility is really needed here, I think a better approach than
arbitrarily changing the contents of this structure would be to simply
define a new structure, BIO_METHOD2, or similar, and have new APIs to
construct BIOs with these methods (or, for APIs which must handle any
version, to have a "version" parameter to tell you which variety you
have). This approach seems to make it much simpler to reason about what
must be supported to ensure both backwards and forwards compatibility.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
