Someone was claiming no files under CVS control are modified in place. A make on the current sources will regenerate obj_dat.h because objects.h changed, and both are in CVS. My make generated a slightly different obj_dat.h than what's in the repository - the two compression objects are in reversed order. According to the list archives that's because obj_dat.pl tries to parse "666L.1L" and "666L.2L" as integers and ends up thinking they're equal. The reversed order is due to a difference in behavior between versions of perl. Here's a patch to change those periods to commas so they'll be parsed right and stored as 2 separate encodings, in a consistent order. Note that the resulting changes in obj_dat.h are substantial because of the way the encodings are stored and referenced. Is this the right fix? Alternatives would be to fix obj_dat.pl instead, or to delete these bogus objects from objects.h entirely. Where are or were these objects used anyway? Index: objects.h =================================================================== RCS file: /CVS/openssl/crypto/objects/objects.h,v retrieving revision 1.18 diff -u -r1.18 objects.h --- objects.h 1999/07/27 22:22:57 1.18 +++ objects.h 1999/07/28 19:49:31 @@ -661,12 +661,12 @@ #define SN_rle_compression "RLE" #define LN_rle_compression "run length compression" #define NID_rle_compression 124 -#define OBJ_rle_compression 1L,1L,1L,1L,666L.1L +#define OBJ_rle_compression 1L,1L,1L,1L,666L,1L #define SN_zlib_compression "ZLIB" #define LN_zlib_compression "zlib compression" #define NID_zlib_compression 125 -#define OBJ_zlib_compression 1L,1L,1L,1L,666L.2L +#define OBJ_zlib_compression 1L,1L,1L,1L,666L,2L #define SN_ext_key_usage "extendedKeyUsage" #define LN_ext_key_usage "X509v3 Extended Key Usage" ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
