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"
<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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
