[Fwd: [Python-Dev] test_gettext.py fails on 64-bit architectures]

[Mark Favas]

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 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."""

-- 
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--