[Python-Dev] issues with int/long on 64bit platforms - eg stringobject (PR#306)

[Guido van Rossum]

The email below is a serious bug report.  A quick analysis shows that
UserString.count() calls the count() method on a string object, which
calls PyArg_ParseTuple() with the format string "O|ii".  The 'i'
format code truncates integers.  It probably should raise an overflow
exception instead.  But that would still cause the test to fail --
just in a different way (more explicit).  Then the string methods
should be fixed to use long ints instead -- and then something else
would probably break...

--Guido van Rossum (home page: http://www.python.org/~guido/)

------- Forwarded Message

Date:    Mon, 24 Apr 2000 19:26:27 -0400
From:    mark.favas@per.dem.csiro.au
To:      python-bugs-list@python.org
cc:      bugs-py@python.org
Subject: [Python-bugs-list] 1.6a2 issues with int/long on 64bit platforms - eg 
	  stringobject (PR#306)

Full_Name: Mark Favas
Version: 1.6a2 CVS of 25 April
OS: DEC Alpha, Tru64 Unix 4.0F
Submission from: wa107.dialup.csiro.au (130.116.4.107)


There seems to be issues (and perhaps lurking cans of worms) on 64-bit
platforms
where sizeof(long) != sizeof(int).

For example, the CVS version of 1.6a2 of 25 April fails the UserString
regression test. The tests fail as follows (verbose set to 1):

abcabcabc.count(('abc',))  no
'abcabcabc' <method UserString.count of UserString instance at 140217e40> 3 <>
2
abcabcabc.count(('abc', 1))  no
'abcabcabc' <method UserString.count of UserString instance at 140216580> 2 <>
1
abcdefghiabc.find(('abc', 1))  no
'abcdefghiabc' <method UserString.find of UserString instance at 140216730> 9 <
>
- -1
abcdefghiabc.rfind(('abc',))  no
'abcdefghiabc' <method UserString.rfind of UserString instance at 140216580> 9
<> 0
abcabcabc.rindex(('abc',))  no
'abcabcabc' <method UserString.rindex of UserString instance at 140216dc0> 6 <>
3
abcabcabc.rindex(('abc', 1))  no
'abcabcabc' <method UserString.rindex of UserString instance at 140216730> 6 <>
3

These tests are failing because the calls from the UserString methods to the
underlying string methods are setting the default value of the end-of-string
parameter to sys.maxint, which is defined as LONG_MAX (9223372036854775807),
whereas the string methods in stringobject.c are using ints and expecting them
to be no larger than INT_MAX (2147483647).
Thus the end-of-string parameter becomes -1 in the default case. The size of an
int on my platform is 4, and the size of a long is 8, so the "natural size of
a Python integer" should be 8, by my understanding. The obvious fix is to
change
stringobject.c to use longs, rather than ints, but the problem might be more
widespread than that. INT_MAX is used in unicodeobject.c, pypcre.c, _sre.c,
stropmodule.c, and ceval.c as well as stringobject.c. Some of these look as
though LONG_MAX should have been used (variables compared to INT_MAX are longs,
but I am not confident enough to submit patches for them...

Mark



_______________________________________________
Python-bugs-list maillist  -  Python-bugs-list@python.org
http://www.python.org/mailman/listinfo/python-bugs-list

------- End of Forwarded Message