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

Mark Favas m.favas@per.dem.csiro.au
Fri, 01 Sep 2000 04:17:14 +0800

This is a multi-part message in MIME format. --------------8FDA7E7BE838D95AC7E3DCE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

-- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913 --------------8FDA7E7BE838D95AC7E3DCE7 Content-Type: message/rfc822 Content-Disposition: inline

Message-ID: <39AEBD01.601F7A83@per.dem.csiro.au> Date: Fri, 01 Sep 2000 04:16:01 +0800 From: Mark Favas <m.favas@per.dem.csiro.au> Organization: CSIRO Exploration & Mining X-Mailer: Mozilla 4.75 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "Barry A. Warsaw" <bwarsaw@beopen.com> Subject: Re: [Python-Dev] test_gettext.py fails on 64-bit architectures References: <39AE07FF.478F413@per.dem.csiro.au> <14766.14278.609327.610929@anthem.concentric.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

Hi Barry,

Close, but no cigar - fixes the miscalculation of BE_MAGIC, but "magic" is still read from the .mo file as 0xffffffff950412de (the 64-bit rep of the 32-bit negative integer 0x950412de)

Mark

"Barry A. Warsaw" wrote:

>>>>> "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 LEMAGIC (defined as MF> 950412DE) and BEMAGIC (calculated as FFFFFFFFDE120495 using MF> struct.unpack('>i',struct.pack('<i', LEMAGIC))[0])_ _I was trying to be too clever. Just replace the BEMAGIC value with_ _0xde120495, as in the included patch._ _MF> Replacing the "i" in the code that generates BEMAGIC 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 LEMAGIC = 0x950412de - BEMAGIC = struct.unpack('>i', struct.pack('<i', LEMAGIC))[0] + BEMAGIC = 0xde120495 def parse(self, fp): """Override this method to support alternative .mo formats."""

-- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913

--------------8FDA7E7BE838D95AC7E3DCE7--