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