On Sat, Jun 07, 2014 at 09:46:38AM -0400, Mike Bland wrote: > > Why do any of the symbols need to be private? Is that degree of > encapsulation necessary, and does it really discourage irresponsible > clients? The source code is open, so people can always build their own > copy and depend on internals if they really want to, and the default > UNIX/Linux/OS X build (i.e. ./configure && make && make test) doesn't > lock down internal symbols. Have dependencies on internal APIs ever > been a problem in practice? > > I'm not saying I feel strongly either way, but it seems that clients > should be clear that the public API is what's available in > openssl/include, and shouldn't depend on anything else. I just don't > understand what making symbols private buys anyone in the context of > OpenSSL, in light of how it appears to complicate the ability to unit > test.
I've seen several cases of projects using symbols that weren't part of the public API. If they really are missing functionality then they should request that something is added to the public API. By not having having the private symbols public I don't have to worry about the API/ABI breaking because something internally changed. And I want to reduce the number of exposed APIs. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
