[Cython] Fix integer width constant names in stdint.pxd

Stefan Behnel stefan_ml at behnel.de
Tue Jan 3 13:10:07 CET 2012


Robert Bradshaw, 03.01.2012 03:00:
> On Mon, Jan 2, 2012 at 5:48 PM, Lisandro Dalcin wrote:
>> On 2 January 2012 22:37, Mansour Moufid wrote:
>>> Now my issue is as follows.
>>>
>>> (I CCed the cython-users list if this question is more appropriate there.)
>>>
>>> I have a simple file, int.pyx:
>>>
>>> from libc.stdint cimport *
>>> print long(UINT8_MAX)
>>> print long(UINT16_MAX)
>>> print long(UINT32_MAX)
>>> print long(UINT64_MAX)
>>>
>>> with the usual setup.py stuff. Compiling and running:
>>>
>>> $ python setup.py build_ext --inplace
>>> ...
>>> int.c:566:3: warning: overflow in implicit constant conversion [-Woverflow]
>>> ...
>>> $ python -c 'import int'
>>> 255
>>> 65535
>>> -1
>>> -1
>>>
>>> So obviously there are overflows here. Checking int.c, I see:
>>>
>>>   /* "int.pyx":2
>>>   * from libc.stdint cimport *
>>>   * print long(UINT8_MAX)             #<<<<<<<<<<<<<<
>>>   * print long(UINT16_MAX)
>>>   * print long(UINT32_MAX)
>>>   */
>>>   __pyx_t_1 = PyInt_FromLong(UINT8_MAX);
>>>
>>> and so on...
>>>
>>> PyInt_FromLong is used for all these constants, regardless of
>>> signedness or width, so any argument larger than LONG_MAX overflows,
>>> *before* being converted to the arbitrary-size Python integer type.
>>>
>>> I don't know if this is a bug, or if I'm overlooking something. Is
>>> there a way for me to use these constants with Python's arbitrary-size
>>> integers?
>>>
>>
>> All these constants are declared as "enum", so Cython promotes them to
>> "int". Once again, Cython should have something like a "const" type
>> qualifier to poperly declare these compile-time constants.
>>
>> As workaround, you could explicitly cast the constants like this
>> "print long(<uint8_t>UINT8_MAX)"
>
> I'm leaning towards declaring them as being the proper type to begin
> with; what's to be gained by declaring these extern values as enums
> (=const)? At least with the larger types we should do this to avoid
> patently incorrect behavior, and this way they would be consistant
> with the actual C for arithmetic promotion, etc.

+1

Stefan


More information about the cython-devel mailing list