Why does OpenSSL own all the prefixes in the world?

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

Post by IÃ±aki Baz Castillo
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.
* 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
SRTP_PROTECTION_PROFILE
[*] https://github.com/joyent/libuv/
--
IÃ±aki Baz Castillo
______________________________________________________________________
OpenSSL Project http://www.openssl.org

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Pierre DELAAGE

2014-09-07 23:15:45 UTC

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

Post by Kyle Hamilton
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"
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.
* 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
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Jakob Bohm

2014-09-08 01:52:21 UTC

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).

Post by Pierre DELAAGE
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

Post by Kyle Hamilton
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"
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.
* 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
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-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Pierre DELAAGE

2014-09-08 04:44:44 UTC

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).

Post by 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).

Post by Kyle Hamilton
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"
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.
* 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
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/

Enjoy
Jakob

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Kyle Hamilton

2014-09-08 13:47:57 UTC

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

Post by Pierre DELAAGE
At a time or another,
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).

Post by 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

Post by Jakob Bohm
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).

Post by Pierre DELAAGE
Hmm...
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES

for

Post by Pierre DELAAGE
things like this.
And I am an old C fan programmer...
Pierre Delaage

the

Post by Kyle Hamilton
prefixes or "namespaces" in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and

others)?

Post by Kyle Hamilton
OpenSSL is a library. I should be able to integrate OpenSSL

into my

Post by Kyle Hamilton
own code and define my own prefixes without worrying about

creating

Post by Kyle Hamilton
conflicts with the near 200 prefixes that OpenSSL owns.
* 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

Post by Kyle Hamilton
do
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/

Enjoy
Jakob

______________________________________________________________________
OpenSSL Project http://www.openssl.org

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Iñaki Baz Castillo

2014-09-08 12:17:10 UTC

Post by 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?

That's the show-stopper rationale. I expect that old projects relying
on OpenSSL should be adapted at some time, otherwise OpenSSL may
provide backward compatibility updates (as it does now). But at some
point bugs must be fixed and, IMHO, the namespace/prefix pollution of
OpenSSL is a bug.

Pierre DELAAGE

2014-09-08 13:59:08 UTC

"Breaking compatibilty" with old apps will occur at a time :
dixit the roadmap :
"Review and revise the public API with a view to reducing complexity
(Timescale: Within one year)"
I suppose that reducing complexity will lead to some rewrites,
elimination/merging some functions...

So it will be the right time to bring some improvements such as C++
namespaces support,
or even macro renaming,
and "breaking binary compatibility" is not really a so big issue :
at a time, if something is rewritten with efficiency and simplicity in
mind, and robustness,
it has to be promoted, pushed to replace past versions.

and binary compatibility is "already" an issue : this is why there are
so many version of openssl,
too many to my mind, so that smart resources of the team are dispersed
to redo and redo again (backporting or forward porting) all the time the
same work.

Anyway, on the short term, for an app maintainer : it is a fact that a
solution to the prefixes mess can be to encapsulate openssl in a custom
lib, hiding anything from the original lib to the external world.

Pierre

Post by Kyle Hamilton
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"
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.
* 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
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/

Enjoy
Jakob

Benny Baumann

2014-09-09 08:06:20 UTC

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.

Post by Kyle Hamilton
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"
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.
* 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
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/

Enjoy
Jakob

Jeffrey Walton

2014-09-08 07:28:07 UTC

Post by Pierre DELAAGE
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...

+1.

C really needs namespaces to avoid collisions and try/finally to
ensure cleanup (cleanup via the finally block).

Jeff

Post by Pierre DELAAGE
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

Iñaki Baz Castillo

2014-09-08 12:13:51 UTC

Post by Pierre DELAAGE
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES for things
like this.

I do code in C++, but I need some C libraries. Regardless my C++ code
is properly "namespaced" I don't like to see so many global C symbols
in it. As I said before, in my case I integrate openssl and libsrtp C
libraries into my C++ project. It 's annoying for me to see that the
macro SRTP_PROTECTION_PROFILE (which I need in my project) is defined
by openssl rather than libsrtp.

Pierre DELAAGE

2014-09-08 12:51:06 UTC

Post by IÃ±aki Baz Castillo

There seems to be some misunderstanding :
My original answer was not directed to you, but to Kyle who was asking
for suggestions to solve your pb.

My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.
that will solve your problem with very limited -or no- impact on other apps.

Post by Pierre DELAAGE
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES for things
like this.

Salz, Rich

2014-09-08 12:57:55 UTC

Post by Pierre DELAAGE
My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.

That would be nice to have. But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)

I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: ***@jabber.me Twitter: RichSalz

�zt�,��-��i��0^��%��Һ�h��X��^��%�ǫ��(z��e��F��)��br ��+

Pierre DELAAGE

2014-09-08 13:36:03 UTC

This is why I just mentioned "namespaces"...

Post by Salz, Rich

Post by Pierre DELAAGE
My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.

That would be nice to have. But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)
I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
:��I"Ϯ��r�m��(��Z+�K�+��1��x��h��[�z�(��Z+��f�y��f��h��)z{,��

Richard Levitte

2014-09-08 14:12:43 UTC

In message <2A0EFB9C05D0164E98F19BB0AF3708C71D12A97663-/***@public.gmane.org> on Mon, 8 Sep 2014 08:57:55 -0400, "Salz, Rich" <rsalz-JqFfY2XvxFXQT0dZR+***@public.gmane.org> said:

rsalz> > My suggestion is indeed that openssl lib switch to C++, at least for
rsalz> > namespace usage.
rsalz>
rsalz> That would be nice to have. But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)
rsalz>
rsalz> I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.

Nothing really stops us from creating a C++ namespace. After all, we
do have the following construct in quite a number if not all exported
header files:

#ifdef __cplusplus
extern "C" {
#endif

/* yada yada yada */

#ifdef __cplusplus
}
#endif

What's stopping us from specifying a namespace in there, technically
speaking? I mean, except for backward compatibility (people will
suddenly HAVE to have a line saying "using namespace openssl;" or
something like that).

Cheers,
Richard
--
Richard Levitte richard-***@public.gmane.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Salz, Rich

2014-09-08 14:29:24 UTC

The extern "C" makes it difficult to put things into a namespace. You'd either have to write class declarations that used NO public openssl header files in their public declaration, or we'd have to change the extern "C" wrappers to be something like
#if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Iñaki Baz Castillo

2014-09-08 22:13:58 UTC

Post by Salz, Rich
The extern "C" makes it difficult to put things into a namespace. You'd either have to write class declarations that used NO public openssl header files in their public declaration, or we'd have to change the extern "C" wrappers to be something like
#if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)

I've tried the "namespace openssl { #include <openssl/xxxx.h> }
approach and it has been terrible. I've ended with compiler error
messages like:

openssl::malloc not found

It makes sense given that the namespace is also affecting to any other
include within the openssl header file.

Michael Wojcik

2014-09-09 11:14:34 UTC

Sent: Monday, 08 September, 2014 18:14
Subject: Re: Why does OpenSSL own all the prefixes in the world?

Post by Salz, Rich
The extern "C" makes it difficult to put things into a namespace. You'd

either have to write class declarations that used NO public openssl header
files in their public declaration, or we'd have to change the extern "C"
wrappers to be something like

Post by Salz, Rich
#if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)

I've tried the "namespace openssl { #include <openssl/xxxx.h> }
approach and it has been terrible. I've ended with compiler error
openssl::malloc not found
It makes sense given that the namespace is also affecting to any other
include within the openssl header file.

You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect.

Mind you, I don't think it's worth the effort, for the reasons I outlined earlier.

--
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
��H��7��m��
)z{,��RǫJ�i��Lj)b��)z{,��M��B���&jw��

Iñaki Baz Castillo

2014-09-09 13:10:16 UTC

Post by Michael Wojcik
You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect.

I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?

Post by Michael Wojcik
Mind you, I don't think it's worth the effort, for the reasons I outlined earlier.

Sure, it was just a vague attempt. And indeed, lot of functions in
OpenSSL are given as macros, so namespaces are of little help.

Thanks a lot.

Michael Wojcik

2014-09-09 15:58:24 UTC

Sent: Tuesday, 09 September, 2014 09:10
Subject: Re: Why does OpenSSL own all the prefixes in the world?

Post by Michael Wojcik
You'd have to include the standard C headers before including the OpenSSL

ones, outside the namespace, so that their inclusion by the OpenSSL headers
has no effect.
I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?

It shouldn't. The C standard says that the second and subsequent inclusion of a standard header has no effect, and I believe the current C++ standard inherits that rule.

All the implementations I know of (with maybe some special exceptions like Splint) implement that with "inclusion guards" - conditional-compilation directives around all the contents of the file.

So if a standard header is included once outside any namespace, then if it's included again inside a namespace, it shouldn't declare anything in that namespace, because all its contents should be skipped. I believe namespaces don't affect macro identifiers, so the guards should work.

I could be wrong about that, though. I haven't tried it myself, and I don't know the C++ standard nearly as well as the C one.

--
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
�zt�,��-��i��0^��%��Һ�h��X��^��%�ǫ��(z��e��F��)��br ��+

Iñaki Baz Castillo

2014-09-09 16:43:58 UTC

Post by Michael Wojcik

Post by IÃ±aki Baz Castillo
I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?

It shouldn't. The C standard says that the second and subsequent inclusion of a standard header has no effect, and I believe the current C++ standard inherits that rule.
All the implementations I know of (with maybe some special exceptions like Splint) implement that with "inclusion guards" - conditional-compilation directives around all the contents of the file.
So if a standard header is included once outside any namespace, then if it's included again inside a namespace, it shouldn't declare anything in that namespace, because all its contents should be skipped. I believe namespaces don't affect macro identifiers, so the guards should work.
I could be wrong about that, though. I haven't tried it myself, and I don't know the C++ standard nearly as well as the C one.

May be I was not clear, but what I mean is:

- Let's suppose openssl/foo.h has a #include <stdlib.h>.

- In myproject.h I add:

namespace myproject {
#include <openssl/foo.h>
}

- And then in myproject.cpp I write:

p = (char*)malloc(sizeof(char) * 100);

Would this produce the "malloc not found, may be you mean
'myproject::malloc'?" error?

PS: Note that I do NOT include <sdtlib.h> in myproject.*.

Michael Wojcik

2014-09-09 17:06:17 UTC

Sent: Tuesday, 09 September, 2014 12:44
Subject: Re: Why does OpenSSL own all the prefixes in the world?
- Let's suppose openssl/foo.h has a #include <stdlib.h>.
namespace myproject {
#include <openssl/foo.h>
}
p = (char*)malloc(sizeof(char) * 100);
Would this produce the "malloc not found, may be you mean
'myproject::malloc'?" error?
PS: Note that I do NOT include <sdtlib.h> in myproject.*.

Yes, in this case I'd expect that error. You need to include stdlib.h outside of any namespace before you include openssl/foo.h.

My advice would be to stick a bunch of include statements for all the standard headers used by any openssl/*.h into a single .h file, and then include that at the top of myproject.h and any other C++ header file that includes an OpenSSL header.

So:

- Create openssl_c_hdrs.h which has:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
...

- Change myproject.h to have:

#include "openssl_c_hdrs.h"
namespace myproject {
#include <openssl/foo.h>
}

Again, I can't say for sure that will work, because I haven't tested it. But it ought to work around this particular issue. The standard headers included by openssl_c_hdrs.h will preempt their inclusion within the namespace by the OpenSSL headers.

Of course, for C++ code you normally wouldn't include the C standard headers; you'd use their C++ versions (<cstdlib>, etc). But this sort of thing is a special case.

--
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
��H��7��m��
)z{,��RǫJ�i��Lj)b��)z{,��M��B���&jw��

Larry Bugbee

2014-09-09 18:07:48 UTC

In the FWIW column.... Please don't mangle names by forcing C++ namespaces. Â Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Â Adding a "OSSL_" prefix is fine; mangling creates huge problems.

-- Sent fm iTouch via Boxer

Yes, in this case I'd expect that error. You need to include stdlib.h outside of any namespace before you include openssl/foo.h.

My advice would be to stick a bunch of include statements for all the standard headers used by any openssl/*.h into a single .h file, and then include that at the top of myproject.h and any other C++ header file that includes an OpenSSL header.

So:

- Create openssl_c_hdrs.h which has:

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

...

- Change myproject.h to have:

#include "openssl_c_hdrs.h"

namespace myproject {

#include <openssl/foo.h>

}

Again, I can't say for sure that will work, because I haven't tested it. But it ought to work around this particular issue. The standard headers included by openssl_c_hdrs.h will preempt their inclusion within the namespace by the OpenSSL headers.

Of course, for C++ code you normally wouldn't include the C standard headers; you'd use their C++ versions (<cstdlib>, etc). But this sort of thing is a special case.

--
Michael Wojcik

Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
???H???7??m????
)z{,???RÇ«J?i??Lj)b????)z{,????)z{,????h??^t???Æ§j??????&??^??%??

Iñaki Baz Castillo

2014-09-09 18:42:54 UTC

The (bad) idea of using C++ namespaces was just targered for those
integrating OpenSSL into their own C++ projects.

Post by Larry Bugbee
In the FWIW column....
Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL
from Python (and other dynamic languages) and depend on the C naming
convention. Adding a "OSSL_" prefix is fine; mangling creates huge
problems.
-- Sent fm iTouch via Boxer

Ted Byers

2014-09-09 20:03:09 UTC

The (bad) idea of using C++ namespaces was just targeted for those
integrating OpenSSL into their own C++ projects.

Now, I would have said that using C++ namespaces was a good idea and
perhaps it might be motivation to replace the MACROs by something more
useful,

I use a number of such languages and it isn't all that hard to mix
them with C++ (in sme cases, I'd extend them using C++ code, for the
sake of performance). In the case of Python, for example, there is a
boost library designed specifically for that purpose. From my
perspective, that is not a big problem. Rather, it is just one of
countless things I routinely have to deal with: just the cost of
getting things done.

Cheers

Ted

--
R.E.(Ted) Byers, Ph.D.,Ed.D.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Larry Bugbee

2014-09-10 04:16:40 UTC

Post by Ted Byers

Hi Ted,

I would probably agree if I were building production systems. But because I build mostly prototypes, quick usually trumps having to deal with the complexity of C++. OpenSSL and LibTom get used a lot because they are C and super easy to call. When I want classes I build them in Python and call the appropriate OpenSSL functions. Life is much, much simpler when I can stick with Python, C, and Python's ctypes. Then again, if I were building a production app....

My best,

Larry

Post by Ted Byers
Cheers
Ted
--
R.E.(Ted) Byers, Ph.D.,Ed.D.
______________________________________________________________________
OpenSSL Project http://www.openssl.org

Pierre DELAAGE

2014-09-10 10:13:25 UTC

Not so bad idea considering that any C program, with modern compilers,
can be compiled as cpp with no problem.
I am mixing code like this for years with no problem.

Other apps, in other languages, that CAN load dynamic libraries, could
take benefit of "c++ to c lib" technique wrapping such as suggested by
other fellow here.
But of course...this can be painful.

Interprocess communication (between a XXX language program and a C++ SSL
translator) is also a possibility.

Considering stunnel is also a very good solution most of the time:
why reinvent the wheel if one just need to talk SSL over TCP...

Post by IÃ±aki Baz Castillo
The (bad) idea of using C++ namespaces was just targered for those
integrating OpenSSL into their own C++ projects.
In the FWIW column....
Please don't mangle names by forcing C++ namespaces. Some us call
OpenSSL from Python (and other dynamic languages) and depend on
the C naming convention. Adding a "OSSL_" prefix is fine;
mangling creates huge problems.
-- Sent fm iTouch via Boxer

Michael Wojcik

2014-09-10 12:29:48 UTC

"Not so bad idea considering that any C program, with modern compilers, can be compiled as cpp with no problem."

That is wildly incorrect. C and C++ (which is what I assume "cpp" means) are different languages.

Here's a C program that conforms to ISO 9899-1999. Try compiling it as C++.

-----
#include <stdlib.h>
char *new(void) {return malloc(1);}
int main(void) {new(); return EXIT_SUCCESS;}
-----

C++ has additional keywords, which invade the C application identifier namespace. It has different syntax and semantics for the void keyword, particularly in the case of function declarations. It has different semantics for void* pointers. It has different rules for numeric-parameter promotions. And so on.

People who think C++ is a superset of C are sadly mistaken, and programmers who act on that assumption are dangerous.

Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
:��I"Ϯ��r�m��(��Z+�K�+��1��x��h��[�z�
b�7��P�i��' ��ޢ�

Pierre DELAAGE

2014-09-10 12:58:41 UTC

Of course there are some differences,
but dealing with those is not a major issue...

And they lead C programs to be more clear, with stronger type management,
more clear function prototypes...

Nothing impossible to manage,
and that is worth managing.

not talking about much better rules and tools to cast pointers.

And I maintain that with modern compilers, and the help of syntax
checking by the compiler,
most C to C++ translation issues can be solved quickly.

By the way, it is a fact that people are already mixing C or C++
programs with C libs, or C++ ones,
and at a time, something impossible in C is possible in C++, like
namespaces.
So that C programmers would not be frustrated by switching to cpp
compilation.

For example, anything you do with pointers in C is possible the same way
in C++.
and you can still program without using any class nor any object if you
are refractory to object programming.

Relying on implicit numerical promotion is always a bad idea, whatever
the language is.

Post by Michael Wojcik
"Not so bad idea considering that any C program, with modern compilers, can be compiled as cpp with no problem."
That is wildly incorrect. C and C++ (which is what I assume "cpp" means) are different languages.
Here's a C program that conforms to ISO 9899-1999. Try compiling it as C++.
-----
#include <stdlib.h>
char *new(void) {return malloc(1);}
int main(void) {new(); return EXIT_SUCCESS;}
-----
C++ has additional keywords, which invade the C application identifier namespace. It has different syntax and semantics for the void keyword, particularly in the case of function declarations. It has different semantics for void* pointers. It has different rules for numeric-parameter promotions. And so on.
People who think C++ is a superset of C are sadly mistaken, and programmers who act on that assumption are dangerous.
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
:��I"Ϯ��r�m��(��Z+�K�+��1��x��h��[�z�(��Z+��f�y��f��h��)z{,��

Michael Wojcik

2014-09-10 13:28:27 UTC

This is not the place to debate the relative merits of C, C++, or the chimerical monstrosity created by pretending the former is the latter. Suffice it to say that there are a number of people who do not agree with the claims you make for treating C as C++, and they are generally people who actually understand the C language.

--
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
�zt�,��-��i��0^��%��Һ�h��X��^��%�ǫ��(z��e��F��)��br ��+

Pierre DELAAGE

2014-09-10 14:18:32 UTC

Pretending that the contrary is impossible and insurmoutable
is just a conservative "fear fud and uncertainty" approach,
based on trivial examples that can/should be expurged from any
industrial program in a couple of minutes.

Understanding C language is not as complicated as C++,
and I am not of those pretending that there is deep science where there
is only some poor syntax concepts in discussion,
and even if I agree that comparing both is not the main subject, it is
anyway in question in this "prefix mess"topic.

I am programming in both for robotics since 20 years, and mixing the two
when obligated to do so,
and provided that you take care of some few differences (I mean for
"functional programming"), it is easy to switch from C to C++ (not the
contrary, of course),

No need to pretend to be a C guru to make possible things appear as
impossible.

Post by Michael Wojcik
This is not the place to debate the relative merits of C, C++, or the chimerical monstrosity created by pretending the former is the latter. Suffice it to say that there are a number of people who do not agree with the claims you make for treating C as C++, and they are generally people who actually understand the C language.

Ted Byers

2014-09-10 15:10:42 UTC

On Wed, Sep 10, 2014 at 9:28 AM, Michael Wojcik

Well Michael, you're partly right. This isn't the place to debate the
relative merits of C and C++, or any other language.

But it smells a bit of extreme arrogance to suggest that those who
disagree with you about the relation between C and C++ do not actually
understand C. Really? You can't be serious.

I have used both for decades. There is no doubt that they are
different programming languages (so I don't fully disagree with you,
but rather think your position is grossly over-stated). At the same
time, they have so much in common that for many software engineers, C
can, for practical purposes, be regarded as a useful subset of C++.
This is certainly true in the suite of problem domains I usually find
myself working on. But, no one would claim C IS C++, because C
doesn't have templates, and thus template meta-programming, or
classes, &c.

Even though I have been using C for decades, there are parts of the
language I have never used. The same is true for C++. And, for those
parts of each language that I do use, C is in fact a subset of C++ and
I really do not care about the differences between the two as I do not
use those parts of either language anyway. I am too busy getting
production code developed, tested and deployed to spend much time
worrying about such things: software that generates anywhere from
hundreds of thousands of dollars to millions of dollars in revenue for
the people for whom I develop the software. I am quite content to let
language lawyers in academia argue about the differences between the
languages (in the taxonomy of anything - natural and artificial
languages, living things, academic taxonomists, there are lumpers who
overemphasize similarities and splitters who overemphasize
differences, and never will the two camps agree, though they DO tend
to produce humorous flame wars that make all involved look foolish),
but, being academics, they are not primarily focused on producing
production quality software.

The original question regarding C++ here involved the observation that
use of C++, and specifically it's support for namespaces, may help
address some, but not all, of the problems related to naming
collisions. That observation is right, but it obviously will carry a
cost. Whether that cost is warranted is a matter of opinion.
Certainly it ought not be ruled out until all other options for
solving the problem at hand have been examined and one, or a small
set, of the available options have been demonstrated as providing the
best solution and the least cost. It will be interesting to watch how
the library evolves over the next decade.

Cheers

Ted

Michael Wojcik

2014-09-08 14:33:25 UTC

Sent: Monday, 08 September, 2014 10:13
Nothing really stops us from creating a C++ namespace. After all, we
do have the following construct in quite a number if not all exported
#ifdef __cplusplus
extern "C" {
#endif
/* yada yada yada */
#ifdef __cplusplus
}
#endif
What's stopping us from specifying a namespace in there, technically
speaking? I mean, except for backward compatibility (people will
suddenly HAVE to have a line saying "using namespace openssl;" or
something like that).

Since all the OpenSSL declarations are in an extern-C block, identifier names aren't mangled, so the namespace has no effect on external visibility. And namespaces don't affect macro names. So there's little benefit - it'd be a purely lexical change that only affects how OpenSSL functions are named within C++ translation units. It doesn't help with macro or external-symbol identifier collisions.

And anyone who wants this can simply include the OpenSSL headers within a namespace declaration.
--
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

Iñaki Baz Castillo

2014-09-08 12:10:25 UTC

Post by Kyle Hamilton
To meet the goal of interoperability while enabling an alternate symbolic
namespace, what would you suggest?

Not a big expert in these subjects, but a workaround coming to my mind
is the following:

- Prefix ALL the OpenSSL symbols with the "OPENSSL_" prefix.

- Include a m4 replacement in the whole source code of openssl with a
compiler --enable-global-prefix option to enable or disable it. This
is, when disabled the "OPENSSL_" prefix becomes an empty string and
nothing changes.

- By default the compiler option is disabled, but the project
announces this feature and encourages people to enable it and update
their projects.

- At some time the option becomes enabled by default.

Michael Wojcik

2014-09-08 13:01:47 UTC