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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> 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...

All uses in stringobject.c and unicodeobject.c use INT_MAX
together with integers, so there's no problem on that side
of the fence ;-)

Since strings and Unicode objects use integers to describe the
length of the object (as well as most if not all other
builtin sequence types), the correct default value should
thus be something like sys.maxlen which then gets set to
INT_MAX.
 
I'd suggest adding sys.maxlen and the modifying UserString.py,
re.py and sre_parse.py accordingly.

> --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
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/