"MF" == Mark Favas <m.favas@per.dem.csiro.au> writes:
MF> This is because the magic number is read in by the code in MF> Lib/gettext.py as FFFFFFFF950412DE (hex) (using unpack('<i', MF> buf[:4])[0]), and checked against LE_MAGIC (defined as MF> 950412DE) and BE_MAGIC (calculated as FFFFFFFFDE120495 using MF> struct.unpack('>i',struct.pack('<i', LE_MAGIC))[0]) I was trying to be too clever. Just replace the BE_MAGIC value with 0xde120495, as in the included patch. MF> Replacing the "i" in the code that generates BE_MAGIC and MF> reads in "magic" by "I" makes the test work for me, but MF> there's other uses of "i" and "ii" when the rest of the .mo MF> file is processed that I'm unsure about with different inputs. Should be fine, I think. With < and > leading characters, those format strings should select `standard' sizes: Standard size and alignment are as follows: no alignment is required for any type (so you have to use pad bytes); short is 2 bytes; int and long are 4 bytes. float and double are 32-bit and 64-bit IEEE floating point numbers, respectively. Please run the test again with this patch and let me know. -Barry Index: gettext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/gettext.py,v retrieving revision 1.4 diff -u -r1.4 gettext.py --- gettext.py 2000/08/30 03:29:58 1.4 +++ gettext.py 2000/08/31 10:40:41 @@ -125,7 +125,7 @@ class GNUTranslations(NullTranslations): # Magic number of .mo files LE_MAGIC = 0x950412de - BE_MAGIC = struct.unpack('>i', struct.pack('<i', LE_MAGIC))[0] + BE_MAGIC = 0xde120495 def _parse(self, fp): """Override this method to support alternative .mo formats."""