> 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.
Sigh indeed. Ideally, we'd introduce H for unsigned and then lock
Jack in a room with his Macintosh computer for 48 hours to fix all his
code...
Jack, what do you think? Is this acceptable? (I don't know if you're
still into S&M :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
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