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
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
