On Thu, Jan 10, 2002 at 08:18:34PM +0000, Joe Orton wrote: >>>> Have we changed CRYPTO_NUM_LOCKS between patch levels? I can't recall >>>> that we have. If we have, that's unfortunate.
>>> 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. An application-provided locking callback may now be called with a lock type value of 28 whereas the maximum possible value used to be 27, but value 28 now is CRYPTO_LOCK_DYNLOCK. This means that if this incompatibility becomes a problem for some application, then either - the application is using the 'engine' variant of OpenSSL 0.9.6c (which is 'experimental' according to its documentation), or - the application *itself* is using dynamic looks, meaning that its developers can be hoped to be aware that using a constant-sized buffer of locks is not a good idea :-) -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
