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/
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
