>>> b) compiling our libjpeg with boolean = int (at least on linux) > > This seems the simplest to me. It's not like we're saving 3 bytes of > memory using a char instead of an int for these booleans -- they're > likely passed around in 4-byte registers and 4-byte unpacked structs > anyway. > But I'm skeptical this really fixes the issue, as it'll still be > broken on systems where the flag is flipped the *other* way.
right, but if everyone follows the LSB then those systems shouldn't exist > >>> c) packaging our own version of gtk along with chrome (ha ha ha ha) >>> d) somehow use the system libjpeg for gtk, and our libjpeg for chrome >> e) rename all symbols in our version of libjpeg, like was done in >> libpng (see third_party/libpng/pngusr.h) > > And this one seems the safest to me. I don't think this works. To be more specific, the problem is that client code is supposed to allocate space for certain structures. Those structures include booleans. libjpeg checks to make sure the passed in struct is equal in size to the expected struct size (i.e. that against which it was compiled). Correct me if I misunderstood. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
