What about introducing a openssl_deprecated.h which sole purpose is to throw in a bunch of defines that map ERR_old_style_name OPENSSL_ERR_new_style_name.
To make an old-style codebase compatiblae the only thing to add would be either including openssl_deprecated.h or set a macro on the command line that does so from within the new-style headers (maybe on by default via the configure). And BTW: C++ won't hurt legibility of the source: using some scoped pointers you can cleanup most error paths to become just "return OPENSSL_ERR_new_style_error_name. Regards, BenBE. Am 08.09.2014 03:52, schrieb Jakob Bohm: > And how would you do that without breaking compatibility with every > program (in C, C++ or any other language) that already uses openssl and > depends on the current API names? > > Providing the API, semantics and portability of the original SSLeay > library is thesecond-most important feature of OpenSSL (right after > actually being a secure SSL/TLSimplementation when used correctly). > > On 08/09/2014 01:15, Pierre DELAAGE wrote: >> Hmm... >> Switch strongly and definitely to C++.... >> Not for fancy object programming, but for more practical syntaxES for >> things like this. >> >> And I am an old C fan programmer... >> Pierre Delaage >> >> >> >> Le 08/09/2014 00:04, Kyle Hamilton a écrit : >>> 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> 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 them >>> do >>> you expect the following macro is defined?: >>> >>> SRTP_PROTECTION_PROFILE >>> >>> >>> >>> >>> [*]https://github.com/joyent/libuv/ >>> > > Enjoy > > Jakob
signature.asc
Description: OpenPGP digital signature
