Python 2.2 64-bit und 0xffffffff != -1
Hallo zusammen, ich versuche momentan Python 2.2.3 auf einer 64-bit Maschine zum Laufen zu bekommen. Leider schlägt ein Test in test_compile fehl: eval('0xffffffff') sollte -1 sein, ist aber 4294967295 Der gleiche Code mit den gleichen Patches auf einem 32-bit System funktioniert. Auf beiden Maschinen nutze ich GCC 4.7.2 on linux3. Die Docu für Python 2.2 [1] sagt ausdrücklich: "Plain octal and hexadecimal literals may be as large as 4294967295, but values larger than 2147483647 are converted to a negative value by subtracting 4294967296". Offensichtlich wird dieser Oberflow also nicht geprüft. Bei Python 1.5 und 2.3 ist es der gleiche Effekt. Das wundert mich insbesondere, weil es im README für 2.2.3 bereits Hinweise auf 64-Bit Systeme gibt. Ist das jemanden von Euch auch schon aufgefallen? Gibt es eine Patch? Oder hat jmd. eine Idee, nach was ich suchen kann? (Ich habe mich bereits durch den C-Code gewühlt, aber keinen Ansatzpunkt gefunden.) [1] http://docs.python.org/release/2.2/ref/integers.html -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/quelltext-fur-tolino-shine Kolumne: http://www.cissp-gefluester.de/2010-08-scheingefechte-um-rim Goebel Consult ist Mitglied bei http://www.7-it.de/
Moin,
Python 2.2.3 auf einer 64-bit Maschine
Und Charlie Chaplin haben sie grad auf die Enterprise hochgebeamed. <scnr>
eval('0xffffffff') sollte -1 sein, ist aber 4294967295
Letzteres ist auf ner 64bit-Maschine mit 64bit Integers zu erwarten.
Der gleiche Code mit den gleichen Patches auf einem 32-bit System funktioniert.
Weil durch 32bit-lange Werte da 0xffffffff sowohl 2^32-1 (unsigned interpretation) als auch -1 (signed interpretation) bedeuten kann.
Die Docu für Python 2.2 [1] sagt ausdrücklich: "Plain octal and hexadecimal literals may be as large as 4294967295, but values larger than 2147483647 are converted to a negative value by subtracting 4294967296".
Ich vermute mal, dass das vielleicht eher eine (etwas unglueckliche) Beschreibung des auftretenden Effekts ist, als dass da wirklich etwas subtrahiert wird.
Ist das jemanden von Euch auch schon aufgefallen? Gibt es eine Patch?
Die Frage ist eher, ob der Bug nicht in der Doku ist. Warum benutzt Du eigentlich 2.2? Kannst nicht was aktuelleres nehmen? mfg Thomas
Am 04.03.2014 14:39, schrieb Thomas Waldmann:
Die Docu für Python 2.2 [1] sagt ausdrücklich: "Plain octal and hexadecimal literals may be as large as 4294967295, but values larger than 2147483647 are converted to a negative value by subtracting 4294967296". Ich vermute mal, dass das vielleicht eher eine (etwas unglueckliche) Beschreibung des auftretenden Effekts ist, als dass da wirklich etwas subtrahiert wird.
Deine Analyse trifft genau das, was ich im C-Code gelesen habe. :-) Dennoch steht es ausdrücklich und genau so in der Docu. Und ja, ich brauche Python 2.2. Und Charly Chaplin kann ich mir auch gut auf der Enterprise vorstellen. :-) -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/trustcenter.de-nimmt-es-mit-der-sicherheit... Kolumne: http://www.cissp-gefluester.de/2010-11-it-sicherheit-im-unternehmen-eine-int... Goebel Consult ist Mitglied bei http://www.7-it.de/
participants (2)
-
Hartmut Goebel -
Thomas Waldmann