This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author srid
Recipients eric.smith, loewis, r.david.murray, srid
Date 2010-06-18.20:47:26
SpamBayes Score 6.478831e-05
Marked as misclassified No
Message-id <71632AD4-5DEE-4DA1-98D3-D236693808FD@activestate.com>
In-reply-to <1276886864.69.0.246387150718.issue9020@psf.upfronthosting.co.za>
Content
On 2010-06-18, at 11:47 AM, Eric Smith wrote:

> 
> Eric Smith <eric@trueblade.com> added the comment:
> 
> I suppose that's correct, although I have no way to test it.

I have tested it on Linux 64-bit by running `test.regrtest`. It doesn't seem to break anything.

> I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place.

My conclusive understanding of the problem: `register int` is 4 bytes in size, and this (`c`) is used without any cast as an index to the array _Py_ctype_table (in pyctype.c) ... by passing it to `Py_CHARMASK` which, if CHAR_UNSIGNED is defined (as is the case with AIX compiler), *assumes* that `c` will always be a char. And that assumption is not respected by tokenizer.c:tok_get which (indirectly) passes `register int` to this macro.
History
Date User Action Args
2010-06-18 20:47:29sridsetrecipients: + srid, loewis, eric.smith, r.david.murray
2010-06-18 20:47:26sridlinkissue9020 messages
2010-06-18 20:47:26sridcreate