On Sep 9, 2014, at 1:03 PM, Ted Byers r.ted.by...@gmail.com wrote:
El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com 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
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
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++.
-
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
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
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
On Wed, Sep 10, 2014 at 9:28 AM, Michael Wojcik
michael.woj...@microfocus.com 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
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
2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
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
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
2014-09-09 17:58 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
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
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
-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
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 bug...@seanet.com escribió:
In the FWIW column
Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL
from Python (and
On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo i...@aliax.net 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
2014-09-08 0:04 GMT+02:00 Kyle Hamilton aerow...@gmail.com:
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
2014-09-08 1:15 GMT+02:00 Pierre DELAAGE delaage.pie...@free.fr:
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
2014-09-08 3:52 GMT+02:00 Jakob Bohm jb-open...@wisemo.com:
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
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-
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
: 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
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. :)
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
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
In message
2a0efb9c05d0164e98f19bb0af3708c71d12a97...@usmbx1.msg.corp.akamai.com on Mon,
8 Sep 2014 08:57:55 -0400, Salz, Rich rs...@akamai.com 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
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)
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
2014-09-08 16:29 GMT+02:00 Salz, Rich rs...@akamai.com:
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
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
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
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
31 matches
Mail list logo
