Re: Why does OpenSSL own all the prefixes in the world?

[Ted Byers]

On Wed, Sep 10, 2014 at 9:28 AM, Michael Wojcik
 wrote:
> 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.
>
> --
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

-- 
R.E.(Ted) Byers, Ph.D.,Ed.D.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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.






Le 10/09/2014 15:28, Michael Wojcik a écrit :

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.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

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

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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.


Le 10/09/2014 14:29, Michael Wojcik a écrit :

"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 
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{,��


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[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 
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{,���

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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


Le 09/09/2014 20:42, Iñaki Baz Castillo a écrit :


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


El 09/09/2014 20:39, "Larry Bugbee" > escribió:


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

Re: Why does OpenSSL own all the prefixes in the world?

[Larry Bugbee]

On Sep 9, 2014, at 1:03 PM, Ted Byers  wrote:
>> El 09/09/2014 20:39, "Larry Bugbee"  escribió:
>>> 
>>> 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.
>>> 
> 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.

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


> Cheers
> 
> Ted
> 
> -- 
> R.E.(Ted) Byers, Ph.D.,Ed.D.
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Ted Byers]

On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo  wrote:
> 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,

> El 09/09/2014 20:39, "Larry Bugbee"  escribió:
>>
>> 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.
>>
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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

The (bad) idea of using C++ namespaces was just targered for those
integrating OpenSSL into their own C++ projects.
El 09/09/2014 20:39, "Larry Bugbee"  escribió:

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

RE: Why does OpenSSL own all the prefixes in the world?

[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

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-

> us...@openssl.org] On Behalf Of Iñaki Baz Castillo

> Sent: Tuesday, 09 September, 2014 12:44

> To: openssl-users@openssl.org

> Subject: Re: Why does OpenSSL own all the prefixes in the world?

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

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

>  
> - In myproject.h I add:

>  
>   namespace myproject {

>   #include 

>   }

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

#include 

#include 

...



- Change myproject.h to have:



#include "openssl_c_hdrs.h"

namespace myproject {

#include 

}



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 (, 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??&??^??%??

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, 09 September, 2014 12:44
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> May be I was not clear, but what I mean is:
> 
> 
> - Let's suppose openssl/foo.h has a #include .
> 
> - In myproject.h I add:
> 
>   namespace myproject {
>   #include 
>   }
> 
> - 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  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 
#include 
#include 
...

- Change myproject.h to have:

#include "openssl_c_hdrs.h"
namespace myproject {
#include 
}

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 (, 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

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-09 17:58 GMT+02:00 Michael Wojcik :
>> 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 .

- In myproject.h I add:

  namespace myproject {
  #include 
  }

- 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  in myproject.*.



-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, 09 September, 2014 09:10
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> 2014-09-09 13:14 GMT+02:00 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

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-09 13:14 GMT+02:00 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?


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


-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Monday, 08 September, 2014 18:14
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> 2014-09-08 16:29 GMT+02:00 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  }
> 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.

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

Re: Why does OpenSSL own all the prefixes in the world?

[Benny Baumann]

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.

Am 08.09.2014 03:52, schrieb 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).
> 
> 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"
>>>  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




signature.asc
Description: OpenPGP digital signature

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-08 16:29 GMT+02:00 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  }
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.

-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Richard Levitte
> Sent: Monday, 08 September, 2014 10:13
> To: openssl-users@openssl.org
> 
> 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).

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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

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


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

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Richard Levitte]

In message 
<2a0efb9c05d0164e98f19bb0af3708c71d12a97...@usmbx1.msg.corp.akamai.com> on Mon, 
8 Sep 2014 08:57:55 -0400, "Salz, Rich"  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 rich...@levitte.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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

"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







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" 
 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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Kyle Hamilton]

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 
};

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  
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" 
  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_.

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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

Le 08/09/2014 14:57, Salz, Rich a écrit :

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: rs...@jabber.me Twitter: RichSalz

:��I"Ϯ��r�m
(���Z+�K�+1���x��h���[�z�(���Z+���f�y������f���h��)z{,��


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

While OpenSSL's namespace polution is certainly a problem - and a problem that 
was (in general) widely discussed in the C programming community at least as 
far back as the late 1980s - it's worth noting that it's a widespread issue 
that affects pretty much all languages of C's generation and earlier, and many 
application libraries.

For example, SGI's original GL library contained external identifiers like 
"c3d", which clearly stomped all over the namespace with unexpected collisions. 
Even today's OpenGL 4, which uses a "gl" prefix for some identifiers, has 
things like "any" - conceivably something an application would use.

Of course there are historical reasons, chiefly to do with limited resources 
and concommittant limitations in OS tooling. The original C standard 
(ISO9989-1990) only required implementations to recognize 31 significant 
characters in an internal identifier - which certainly limits the scope for 
namespace prefixes - and only *6* characters for an external identifier, which 
all but rules them out. (The implementation can also treat external identifiers 
as case-insensitive for linking purposes.)

There is no good solution to this. m4 preprocessing is not available (by 
default) on all OpenSSL platforms, and is fraught with complications, as is any 
other preprocessing solution: it complicates debugging, for example, and has to 
handle various complicated cases such as an apparent or actual identifier in 
quoted strings, macro expansions, and the like. Implementing an optional 
namespace using C preprocessor tricks such as token-pasting is an infeasible 
effort and similarly fraught. Moving to C++ breaks binary compatibility (due to 
name-mangling, etc), requires a new build system, likely breaks some supported 
platforms, and runs the risk of introducing failures due to the many 
differences between C and C++ - and it does nothing for macro names. (In 
general, compiling C as C++ is a Bad Idea, despite the claims of C++ 
proponents.)

What *is* feasible is wrapping OpenSSL in a library that provides the 
functionality your application needs, and imposes the namespace protections you 
want (along with any enhanced functionality, etc), while hiding OpenSSL's 
symbols (by not exporting the external linkage symbols and not exposing the 
macros to the application). That's what we do. Few applications will use all, 
or even most, of OpenSSL's public functionality directly anyway.

Michael Wojcik
Technology Specialist, Micro Focus


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Kyle Hamilton
Sent: Sunday, 07 September, 2014 18:04
To: openssl-users@openssl.org; Iñaki Baz Castillo
Subject: Re: 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
On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" 
mailto: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 t!

 hem

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.


This message has been scanned for malware by Websense. www.websense.com

RE: Why does OpenSSL own all the prefixes in the world?

[Salz, Rich]

> 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: rs...@jabber.me Twitter: RichSalz

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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.




Le 08/09/2014 14:13, Iñaki Baz Castillo a écrit :

2014-09-08 1:15 GMT+02:00 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.




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-08 3:52 GMT+02:00 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.


-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-08 1:15 GMT+02:00 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.


-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-08 0:04 GMT+02:00 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.



-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Jeffrey Walton]

On Sun, Sep 7, 2014 at 7:15 PM, 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...
+1.

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

Jeff

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

Re: Why does OpenSSL own all the prefixes in the world?

[Pierre DELAAGE]

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" 
 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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

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

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" 
 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 Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[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



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

Re: Why does OpenSSL own all the prefixes in the world?

[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"  
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/
>
>
>-- 
>Iñaki Baz Castillo
>
>__
>OpenSSL Project http://www.openssl.org
>User Support Mailing Listopenssl-users@openssl.org
>Automated List Manager   majord...@openssl.org

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

Why does OpenSSL own all the prefixes in the world?

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


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/


-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org