Re: cvs commit: openssl/crypto/bn bn.h bn_exp.c bn_exp2.cbn_gcd.cbn_lib.c bn_mont.c bn_mul.c bn_prime.c bn_recp.c bn_shift.cbn_sqr.cbntest.c

[Richard Levitte - VMS Whacker]

From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>

[Finally removed the cc: to openssl-cvs-...]

levitte> It does mean exactly that.  If we want to constify the API, what
levitte> choice do we have?  Also, note that in the problematic sections,
levitte> there's a check to see that the BIGNUM data isn't flagged as static.
levitte> 
levitte> This *is* a conflict between the wish to constify and efficiency.  If
levitte> you have some elegant solution, please tell us.

Oh, wait, you did say something about have to variants of BN_mul(),
one that's constified (and slower because it would use bn_dup_expand)
and one unconstified.

I'm personally not sure I like this kind of duplication of code.  It
doubles the maintainance requirements, which is basically a bad thing
(I've seen too many of those where you fix a bug in one variant and
forget that it needs to be fixed twice).  I think I view unconstification
as less bad if you are fairly sure it can be done.

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]