MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> Slight tangent: I just diffed the jmorecfg.h from the >> jpeg-6b that we >>> distribute, against the jmorecfg.h from jpeg-8a that is the latest I >>> have here, and I notice that, whilst they are broadly the >> same, that 6b >>> typedefs "boolean" as char, whilst 8a (and 7 as it happens) >> typedef it >>> as an int... >>> >>> Might be relevant? >> Might be... It' getting even more weird if you look at jpeglib.h (6b), >> where it is defined as unsigned char, at least under certain >> circumstances. > > In jpeglib.h?
Sorry, no, that was a typo. I wanted to check and correct it, but was distracted somehow. :-( > I don't see it defined at all in jpeglib.h, in any of 6b, 7 or 8a - I > only see it defined in jmorecfg.h in all of them. It's in *FLTK's* jconfig.h (as I wrote before), but it's not in the "real" one's (6b). > And... This is where it gets a bit weird. > > I have looked at two versions of 6b - the one bundled in fltk, and a > "real" one that I pulled from the net. > > Looking in jmorecfg.h, the "real" one has: > > typedef int boolean; > > (which is the same as versions 7 and 8a have.) > > The one bundled with fltk-1.1, 1.3 and 2.x has: > > typedef char boolean; > > Which rather suggests that "we" have changed this typedef at some point > in the past - why, I don't know. Okay, let's see: (1) the "real" versions, downloaded from the 'net: $ for d in jpeg-* ; do grep boolean $d/*.h | grep typedef ; done jpeg-6b/jmorecfg.h:typedef int boolean; jpeg-6b/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); jpeg-7/jmorecfg.h:typedef int boolean; jpeg-7/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); jpeg-8/jmorecfg.h:typedef int boolean; jpeg-8/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); jpeg-8a/jmorecfg.h:typedef int boolean; jpeg-8a/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); jpeg-8b/jmorecfg.h:typedef int boolean; jpeg-8b/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); (2) FLTK 1.3: $ grep boolean fltk-1.3/jpeg/*.h | grep typedef fltk-1.3/jpeg/jconfig.h:typedef unsigned char boolean; fltk-1.3/jpeg/jmorecfg.h:typedef char boolean; fltk-1.3/jpeg/jpeglib.h:typedef JMETHOD(boolean, jpeg_marker_parser_method, (j_decompress_ptr cinfo)); Note the mismatch of 'unsigned char' and 'char' in the different files in FLTK's version, whereas it is 'int' in the "real" versions. > Since I sometimes build using the built-in libs, but usually with the > system libs, it would appear that this change does not affect the > functionality. But if so, why did we ever change it? It just seems > spurious to me... Yes, indeed, making a diff of the "real" 6b version and FLTK's one shows lots of diffs. Some seem to be simple renames, some are dependencies, some Makefile diffs, but I don't know what else. The most significant ones seem to be the changed typedef's, though. That looks bad :-( . I was used to update the bundled libpng by more or less dropping in the new files (after carefully checking diffs, of course), but this looks like real work... Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
