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 vstinner
Recipients Devin Jeanpierre, mark.dickinson, skrah, vstinner
Date 2013-05-01.21:09:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1367442544.15.0.0315249902469.issue17884@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, I think I understood the issue :-) The problem is when the uint32_t type is present but is not exactly 32-bit width. When using uint32_t, *I* expect that an array of uint32_t items will takes 4 x n bytes. In which case is it interesting to use an uint32_t which may be bigger? If there is an use case (speed maybe?), we should define a Py_uint32_t which is always present and always exaclty 32 bits. If there is no use case (ex: int_fast32_t or int_least32_t can be used instead), it is maybe better to replace the available type using a #define to use the expect type.
History
Date User Action Args
2013-05-01 21:09:04vstinnersetrecipients: + vstinner, mark.dickinson, Devin Jeanpierre, skrah
2013-05-01 21:09:04vstinnersetmessageid: <1367442544.15.0.0315249902469.issue17884@psf.upfronthosting.co.za>
2013-05-01 21:09:04vstinnerlinkissue17884 messages
2013-05-01 21:09:03vstinnercreate