> I broke it with my patches to test overflow for some of the PyArg_Parse*()
> formatting characters. The upshot of testing for overflow is that now those
> formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or
> unsigned-ness as appropriate (you have to know if the value is signed or
> unsigned to know what limits to check against for overflow). Two
> possibilities presented themselves:
I think this is a _very_ bad idea. I have a few thousand (literally) routines
calling to Macintosh system calls that use "h" for 16 bit flag-word values,
and the constants are all of the form
kDoSomething = 0x0001
kDoSomethingElse = 0x0002
...
kDoSomethingEvenMoreBrilliant = 0x8000
I'm pretty sure other operating systems have lots of calls with similar
problems. I would strongly suggest using a new format char if you want
overflow-tested integers.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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