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