On Thu, Jan 10, 2002 at 08:52:36PM +0100, Richard Levitte - VMS Whacker wrote: > From: Joe Orton <[EMAIL PROTECTED]> > > jorton> On Thu, Jan 10, 2002 at 06:52:53PM +0100, Richard Levitte - VMS Whacker >wrote: > jorton> > It would. That's why the function CRYPTO_num_locks() exists. > jorton> > > jorton> > It's unfortunate that CRYPTO_NUM_LOCKS is exported... > jorton> > > jorton> > Have we changed CRYPTO_NUM_LOCKS between patch levels? I can't recall > jorton> > that we have. If we have, that's unfortunate. > jorton> > jorton> Yes, afraid so, these changed between "b" and "c"... the only other > > Hmm. Thinking of it, I'm not sure if that should count as an > incompatibility. At least not in the same way as, say, and API > change. But it does require the user to use functions like > CRYPTO_num_locks() instead of macros like CRYPTO_NUM_LOCKS.
Well, if it means an application which used the CRYPTO_NUM_LOCKS value which was compiled against 0.9.6b headers would not work correctly if relinked (but not recompiled) against 0.9.6c, that means backwards incompatibility. It sounds like this is the case. > jorton> change I see which might affect compatibility is the changes to OBJ_ > jorton> definitions in obj_mac.h, I'm not sure if these matter as well. > > These do not count. The only trouble would be if the nids changed > values. The OID changes were required since the previous ones were > incorrect (in other words, that was a real bug fix :-)). Okay -- thanks! joe ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
