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--
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4