[Python-Dev] test_gettext.py fails on 64-bit architectures (original) (raw)

Barry A. Warsaw bwarsaw@beopen.com
Thu, 31 Aug 2000 06:47:34 -0400 (EDT)

"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