Hi Jack, I am your evil man for this one (but then you already knew that). On Tue, Jul 04, 2000 at 11:50:02PM +0200, Jack Jansen wrote: > I've adapted PyArg_ParseTuple (and Py_BuildValue) to understand the H > format specifier, which is meant for 16-bit bitpatterns. (in case you > didn't follow the discussion last month: the old lowercase h now > checks values to be in the range -32768..32767, so constants like > 0x8000 are not acceptable anymore). I think that the Right Answer is: b = signed byte B = unsigned byte h = signed short H = unsigned short i = signed int I = unsigned int l = signed long L = unsigned long Before my patch we had (no range checking was done so signed vs. unsigned made no difference): b = byte h = short i = int l = long L = LONG_LONG After my patch (i.e. now) we have: b = unsigned byte h = signed short i = signed int l = signed long L = signed LONG_LONG Notes on that: - Choosing signed or unsigned for each was based on the common case (or presuming what the common case was). I.e. unsigned bytes are more common than signed bytes. - unsigned byte is 'b' and not (my ideal) 'B', for backward compatibility reasons - LONG_LONG as 'L' really sucks because that is the blocker to PyArg_ParseTuple nirvana (my first list). It should be 'q' and 'Q' for Quad or something like that. Your patch is adding (right?): H = unsigned short Aside: Now that it will be called 2.0 would we maybe want to go for the Right Answer. I suspect that a *lot* more people would complain of breakage with the use of 'L' changing to 'Q', and that I am asking for a lynching. > > I haven't added an I and L specifier, because (surprise, surprise:-) > for 32-bit integers 0x80000000 turns out to be a legal value, unlike > for their poor 16-bit brethren. I can't see how 'I' allows 0x80000000 (unless, of course, sizeof(int) > 4 on your machine) because the 'I' formatter is not in PyArg_ParseTuple. Yes, 'L' will probably accept 0x80000000 because LONG_LONG is probably 64-bits wide on your machine hence. > > I've currently implemented H as meaning unsigned (i.e. 0..0xffff), but I woudl suggest allowing [0, USHRT_MAX]. Should be defined in limits.h (guessing), I think. > on second thoughts I think allowing -32768..0xffff might be better: > there's probably lots of code out there that passes -1 when all 16 > flag bits should be set. Please let me know if you have strong I think that uses of -1 should use either USHRT_MAX or (unsigned short)-1. > opinions on either meaning before I check this in. > > <grumpy mode="on">Note that I'll only adapt PyArg_ParseTuple and the > gazzilion mac-specific occurrences of "h" where a 16-bit pattern is > needed. I've done only a very cursory check of other occurences of > "h", but someone else will have to pick that up if they feel like. > </grumpy> I am sorry to have been the cause of work for you. I just think that the 'security' offered by bounds checking all values converted by PyArg_ParseTuple is important. 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