If all you want is C++ namespaces,could you you wrap the #include lines for
OpenSSL in a namespace declaration? (I am not a C++ guy, I honestly don't know
where problems would exist... except the namespaces don't do anything for
#define, I think?)
namespace openssl {
#include <ssl/whatever.h>
};
Another alternative might be to not mix code that relies on defined symbols
from one library in the same source file as one which requires a different
library with conflicting definitions. This would require passing context
structs to functions in different source files, with those functions doing what
needed to happen at that moment using the facilities available to that source
file.
A bigger problem is that it would necessarily change the ABI to dictate that
the symbols in the linked library cannot be linked as extern "C".
Perhaps a compatibility library that forwards old-API calls to a namespaced
library could work... but the problem there is that there are platforms still
in use that likely have only limited C++ support. (Such as Amiga and OS/2.)
It's not an easy problem to address, and every option has compromises.
-Kyle H
On September 7, 2014 9:44:44 PM PST, Pierre DELAAGE <[email protected]>
wrote:
>At a time or another,
>of course there would be some (hopefully limited) rewrite in apps :
>
>not necessarily complicated: I was thinking about C++ namespaces.
>
>It is also possible to offer to apps maintainers a global "grep and
>replace" script, based on "ed" or "vi" in an automated way,
>to replace every BIO_xxx by, eg, OSSL_BIO_xxx in all files in some
>location.
>Not so difficult either.
>
>From year to year, It would be strange that openssl is maintaining, by
>huge effort, various versions of the library (I mean for any given
>platform, whatever it is),
>just to "avoid" that old apps be maintained themselves doing "lesser"
>effort.
>I do not see so big problems with that, provided that, apart from
>adapting some code, people are NOT pushed to buy, to pay, to invest, to
>
>migrate to other platform (a strategy that many OS vendors have).
>
>If there is a switch to C++ one day, and/or a change in the API design,
>there can be a kind of progressive "switching" period where two api's
>coexist,
>one giving wrappers/redirectors to the other, or one being built on top
>
>of the other, encapsulating it and -later- making the other "NOT"
>public
>and then maybe completely disappearing .
>
>It would be interesting, in that perspective, to have some statistics
>about the API functions REALLY in use in apps.
>By some smart greps scripts that could be part of the openssl distrib
>(so that people avoid to reinvent the wheel and all use the same tool
>for such measurements).
>
>
>
>Le 08/09/2014 03:52, Jakob Bohm a écrit :
>> 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"
>>>> <[email protected]> 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
>
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>User Support Mailing List [email protected]
>Automated List Manager [email protected]
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
