On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote:
> > 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.
Sigh. What do you think Guido? This is your call.
1. go back to no bounds testing
2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and
unsigned values but is sort of false security for bounds checking)
3. keep it the way it is: 'b' is unsigned and the rest are signed
4. add new format characters or a modifying character for signed and unsigned
versions of these.
Trent
--
Trent Mick
trentm@activestate.com
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