On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote:
Avery Pennarun via RT wrote:
On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote:
Good question, but this problem does not appear to apply to C, and
anyway it only makes *existing* code uglier -- for new code, the
modified
Bodo Moeller wrote:
On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote:
Avery Pennarun via RT wrote:
On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote:
Good question, but this problem does not appear to apply to C, and
anyway it only makes *existing* code uglier -- for
Avery Pennarun [EMAIL PROTECTED]:
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
On Sat, Jun 15, 2002 at 12:14:00PM +0200, Bodo Moeller wrote:
Using const unsigned char **, however, is not 100% api-compatible, because
you can't safely pass an unsigned char ** to it, for complicated reasons
explained in the URL I sent earlier.
Avery Pennarun [EMAIL PROTECTED]:
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
On Sat, Jun 15, 2002 at 12:14:00PM +0200, Bodo Moeller wrote:
Using const unsigned char **, however, is not 100% api-compatible, because
you can't safely pass an unsigned char ** to it, for complicated reasons
explained in the URL I sent earlier.
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
d2i_RSAPrivateKey(RSA **a,
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
d2i_RSAPrivateKey(RSA **a,
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
[...]
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length);
ie., without a const on
On Wed, Nov 08, 2000 at 07:34:33AM -0800, Geoff Thorpe wrote:
[...]
whose internals are generally only managed inside OpenSSL anyway. Eg. the
caller may pass a const X509* pointer, but the caller is generally not
supposed to be using the structure's internals directly anyway - the use
of
The BN_LLONG version of bn_add_words() didn't get constified in the recent
changes, so it isn't consistent with its prototype. This is fixed by the
patch below.
/Krister
--- openssl-SNAP-20001117/crypto/bn/bn_asm.c.bakFri Nov 17 00:00:26 2000
+++ openssl-SNAP-20001117/crypto/bn/bn_asm.c
to
have two API's in the first place; you might as well just leave it
simple with one API. Or, avoid the const altogether, but I think lhash
really is an appropriate place for constification.
bl But I'll freely admit that this is probably an API too far in
bl lhash's case.
I think we're in viole
he readers of this mail group. My point is
that if the constification can be made to the exposed APIs without
causing undo performance degradation or code breakage then I'm for
it. Even if only half of the exposed function parameters can be constifyed
then that is at least self-documenting code which helps those of us from
a
%% Ben Laurie [EMAIL PROTECTED] writes:
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
bl The latter.
To me, that's much more ugly than simply casting it.
This is C, not C++, and we do the best we can with
"Paul D. Smith" wrote:
%% Ben Laurie [EMAIL PROTECTED] writes:
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
bl The latter.
To me, that's much more ugly than simply casting it.
This is C, not
Richard Levitte - VMS Whacker wrote:
From: Ben Laurie [EMAIL PROTECTED]
ben Like strstr()...
ben
benbl Just because the C libraries are broken doesn't mean we should
benbl break ours. In Apache we fix these rather than live with them.
ben
ben How exactly do you fix them?
From: Ben Laurie [EMAIL PROTECTED]
ben No, you have two, a const and a non-const version.
Fine, I'll give it a shot. I do not believe in it, but I will.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken
"Paul D. Smith" wrote:
%% Ben Laurie [EMAIL PROTECTED] writes:
bl By wrapping them with correctly declared functions.
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
The latter.
I don't think either of
such a
string must make a local copy first.
My .02 cents worth...
- Original Message -
From: Lutz Jaenicke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 08, 2000 10:08 AM
Subject: Re: Constification
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker
wrote
API designer's case study in encapsulation, let
alone a worthwhile example of "const"ification. For starters, generally
there is no illusion of binary compatibility maintained, and direct access
to Apache structures is actively encouraged anyway.
I've butted heads with this consti
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 07, 2000 8:55 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Constification
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to
Richard Levitte - VMS Whacker wrote:
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
Like strstr()...
Just because the C libraries are broken
%% Ben Laurie [EMAIL PROTECTED] writes:
Like strstr()...
bl Just because the C libraries are broken doesn't mean we should
bl break ours. In Apache we fix these rather than live with them.
How exactly do you fix them?
--
From: Ben Laurie [EMAIL PROTECTED]
ben Like strstr()...
ben
benbl Just because the C libraries are broken doesn't mean we should
benbl break ours. In Apache we fix these rather than live with them.
ben
ben How exactly do you fix them?
ben
ben By wrapping them with correctly
%% Ben Laurie [EMAIL PROTECTED] writes:
bl By wrapping them with correctly declared functions.
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
I don't think either of these two options is better than deconstifying
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker wrote:
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1,
Richard Levitte - VMS Whacker wrote:
I've become irritated enough with some functions not having const used
properly (or at least what appears proper), so I've started working on
bringing better use of const to OpenSSL, as some may already have
noticed.
This may, for a few days, bring
From: Dr S N Henson [EMAIL PROTECTED]
drh There's a couple of areas I noticed that could be constified. The EVP
drh library's use of EVP_MD and EVP_CIPHER is the main one. I also noticed
drh that the version strings for some reason weren't constified.
Thanks, I'll look at those next (after I've
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
Like strstr()...
psmith IMHO this is a legitimate reason to cast away const, and that
psmith the "const"
%% Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
rl From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
rl Like strstr()...
Yep. Plus
On Tue, Nov 07, 2000, Paul D. Smith wrote:
I sent this patch back on 05 May 2000, constifying crypto/lhash.
Your patch can only be accepted if you CC it to [EMAIL PROTECTED]
__
OpenSSL Project
I've become irritated enough with some functions not having const used
properly (or at least what appears proper), so I've started working on
bringing better use of const to OpenSSL, as some may already have
noticed.
This may, for a few days, bring along a number of warnings or errors
because
I've started working on bringing better use of const to OpenSSL
Huzzah.
Also, this will bring about a few ugly casts in the ASN.1 macros or
direct callers of them.
Perhaps something like
#define CONST(t, p) (const t)(p)
#define UNCONST(t, p) (t)(p)
As in
extern void
From: Ben Laurie [EMAIL PROTECTED]
ben Woah! Let's not get carried away - unless they gain is actually zero,
ben then constification is not justification, in itself, for doing this.
ben Note, you could have a constified version that either didn't do
ben BN_RECURSION or copied instead
,
then constification is not justification, in itself, for doing this.
Note, you could have a constified version that either didn't do
BN_RECURSION or copied instead of expanding.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't
carried away - unless they gain is actually zero,
then constification is not justification, in itself, for doing this.
Note, you could have a constified version that either didn't do
BN_RECURSION or copied instead of expanding.
I think copying wouldn't be the way to do it -- rather, merely check
36 matches
Mail list logo
