[Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow (original) (raw)
Guido van Rossum guido at python.org
Thu Jun 27 00:26:05 CEST 2013
- Previous message: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
- Next message: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jun 26, 2013 at 3:07 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
I don't understand why the B, H, I, k formats of PyArgParseTupe() 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; UINTMAX] 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 PyLongCheck(), PyLongAsLong(), and check value <= UINTMAX?
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)
- Previous message: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
- Next message: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]