While OpenSSL's namespace polution is certainly a problem - and a problem that was (in general) widely discussed in the C programming community at least as far back as the late 1980s - it's worth noting that it's a widespread issue that affects pretty much all languages of C's generation and earlier, and many application libraries.
For example, SGI's original GL library contained external identifiers like "c3d", which clearly stomped all over the namespace with unexpected collisions. Even today's OpenGL 4, which uses a "gl" prefix for some identifiers, has things like "any" - conceivably something an application would use. Of course there are historical reasons, chiefly to do with limited resources and concommittant limitations in OS tooling. The original C standard (ISO9989-1990) only required implementations to recognize 31 significant characters in an internal identifier - which certainly limits the scope for namespace prefixes - and only *6* characters for an external identifier, which all but rules them out. (The implementation can also treat external identifiers as case-insensitive for linking purposes.) There is no good solution to this. m4 preprocessing is not available (by default) on all OpenSSL platforms, and is fraught with complications, as is any other preprocessing solution: it complicates debugging, for example, and has to handle various complicated cases such as an apparent or actual identifier in quoted strings, macro expansions, and the like. Implementing an optional namespace using C preprocessor tricks such as token-pasting is an infeasible effort and similarly fraught. Moving to C++ breaks binary compatibility (due to name-mangling, etc), requires a new build system, likely breaks some supported platforms, and runs the risk of introducing failures due to the many differences between C and C++ - and it does nothing for macro names. (In general, compiling C as C++ is a Bad Idea, despite the claims of C++ proponents.) What *is* feasible is wrapping OpenSSL in a library that provides the functionality your application needs, and imposes the namespace protections you want (along with any enhanced functionality, etc), while hiding OpenSSL's symbols (by not exporting the external linkage symbols and not exposing the macros to the application). That's what we do. Few applications will use all, or even most, of OpenSSL's public functionality directly anyway. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Kyle Hamilton Sent: Sunday, 07 September, 2014 18:04 To: openssl-users@openssl.org; Iñaki Baz Castillo Subject: Re: Why does OpenSSL own all the prefixes in the world? The reason is "legacy". Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities. To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest? -Kyle H On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" <i...@aliax.net<mailto:i...@aliax.net>> wrote: Hi, RAND_xxx CRYPTO_xxx ERR_xxx ENGINE_xxx EVP_xxx sk_xxx X509_xxx BIGNUM_xxx RSA_xxx BN_xxx ASN1_xxx EC_xxx etc etc etc. May I understand why it was decided that OpenSSL can own all the prefixes or "namespaces" in the world? How is it possible that OpenSSL owns the ERR_ prefix (for example ERR_free_strings() and others)? OpenSSL is a library. I should be able to integrate OpenSSL into my own code and define my own prefixes without worrying about creating conflicts with the near 200 prefixes that OpenSSL owns. An example of a well designed C library is libuv [*], in which: * Public API functions and structs begin with uv_. * Private API functions begin with uv__. * Public macros begin UV_. That's a good design! PS: In my project I use both openssl and libsrtp. In which of t! hem do you expect the following macro is defined?: SRTP_PROTECTION_PROFILE [*] https://github.com/joyent/libuv/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. This message has been scanned for malware by Websense. www.websense.com
