> (a) What's the "preferred" style in python extension modules > of parsing a number from python into a C type, where the > C type size may change on different platforms? > Is my method of guessing what the largest common size > will be (long, unsigned long, ...), reading into that, > and assigning to the final type, acceptable? Yes, that's the best thing we have come up with. You then have the issue on potential truncation on assignment: if the value passed fits into a long (say) but not an attr_t, it would be good if an error was raised. In the past, we have typically coded that ValueError explicitly after the ParseTuple call. In principle, it is possible to deal with these in ParseTuple. To do so: a) in configure.in, make a configure-time check to compute the size of the type, and possibly its signedness. b) in _cursesmodule.c, make a conditional define of ATTR_T_FMT, which would be either "i" or "l" (or #error if it's neither the size of int nor the size of long). Then rely on string concatenation in using that define. > (b) Is there a desire to see the standard python C extension > modules cleaned up to use the answer to (a), especially > where said modules may be susceptable to the word > size problems I mentioned? Most certainly. There shouldn't be that many places left, though; most have been fixed over the years already. I have a GCC patch which checks for correctness of ParseTuple calls (in terms of data size) if you are interested. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4