Richard Levitte - VMS Whacker wrote:
>
> From: Rich Salz <[EMAIL PROTECTED]>
>
> rsalz> As I see it, you have a couple of choices.
> rsalz> 1. Leave the old code, as shown in the first fragment, but declared the
> rsalz> parameters const. You can't do that, because the resultant code is not
> rsalz> standard-conforming.
> rsalz>
> rsalz> 2. Declare the parameters const, but introduce new local
> rsalz> variables that cast away the const-ness.
>
> You mean something like this?
>
> if (i == 1 && !BN_get_flags(b,BN_FLG_STATIC_DATA))
> {
> BIGNUM *tmp_bn = (BIGNUM *)b;
> bn_wexpand(tmp_bn,al); // modifies b
> tmp_bn->d[al] = 0;
>
> If that's it, I don't quite understand how that differs from casting
> in any other way. BTW, the code given above is exactly what I
> currently have in my work directory as a solution to getting back to
> the old behavior but keeping the constness in the parameters. It does
> still include an evil cast, which I thought was the actual problem
> here.
>
> rsalz> It's a tough call, and almost completely a matter of taste.
>
> Yup... :-)
No!!! Its a matter of being right or wrong. You _cannot_ modify a const.
There are circumstances where you may cast away the const knowing that,
in practice, it will not be modified, but you can never cast it away in
order to be able to modify it. That is just plain wrong and will break
things.
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 mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
