On Wed, Jun 26, 2013 at 3:07 PM, Victor Stinner
I don't understand why the B, H, I, k formats of PyArg_ParseTupe() do not check for overflow, whereas formats for signed numbers do check for overflow. What is the useful of ignoring overflow? http://docs.python.org/3/c-api/arg.html
I think this is really old DNA. It comes from times when 0xffffffff and -1 were equivalent -- we borrowed this cavalier attitude from old C code. I worry that "fixing" this would break some old libraries relying on the feature, so I hope we can avoid changes in this area (the older the DNA, the more hidden dependencies it has ;-).
I would to parse an integer in [0; UINT_MAX] to fix the zlib module on 64-bit system: http://bugs.python.org/issue18294
How should I implement that? Use "O" format and then use PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX?
Why can't you use the K format? It won't reject out-of-range values, but it will convert them to in-range so there aren't any attacks possible based on bypassing the range check. I'm probably misunderstanding something -- I don't completely understand that bug report. :-( -- --Guido van Rossum (python.org/~guido)