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 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've currently implemented H as meaning unsigned (i.e. 0..0xffff), but 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 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> -- 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/ ++++
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