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 mark.dickinson
Recipients Eli.Stevens, mark.dickinson, mark.wiebe
Date 2011-04-04.13:35:23
SpamBayes Score 3.0155154e-06
Marked as misclassified No
Message-id <>
I've only glanced at the patch, but a couple of things:

(1) It looks as though the patch assumes that a C double is IEEE 754 binary64 format, and that a C float is IEEE 754 binary32 format.  Is that correct?

If so, that's a significant break with tradition:  Python's supposed to be able to work with the native doubles, no matter what their format.  I, for one, wouldn't object if IEEE floating-point were made a requirement for Python >= 3.3, but this change would need to be discussed on the python-dev mailing list.

(2)  The

  typedef PY_LONG_LONG npy_uint64;

looks wrong to me for two reasons:  first, PY_LONG_LONG is a signed type.  Second, while it's guaranteed (by the C standard) that unsigned long long will have width at least 64, it's not guaranteed that it'll be exactly 64.  Does the code depend on this assumption?  Similarly when using unsigned int in the union for the 32-bit code;  here it's not even guaranteed by the standards that unsigned int has width at least 32.

It may be better to use the PY_UINT64_T type and the HAVE_UINT64_T macros, and similarly for the 32-bit types.
Date User Action Args
2011-04-04 13:35:24mark.dickinsonsetrecipients: + mark.dickinson, Eli.Stevens, mark.wiebe
2011-04-04 13:35:24mark.dickinsonsetmessageid: <>
2011-04-04 13:35:23mark.dickinsonlinkissue11734 messages
2011-04-04 13:35:23mark.dickinsoncreate