PyArg_ParseTupe(): parse unsigned integer and check for overflow
Hi, 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 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? Victor
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)
On Thu, Jun 27, 2013 at 12:07 AM, Victor Stinner
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?
I ran into the same problem in the _lzma module. My solution was to define
a custom converter that does an explicit check before returning the value
(see http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134).
On Thu, Jun 27, 2013 at 12:26 AM, Guido van Rossum
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. :-(
The point is not to protect against deliberate attacks, but rather to fail loudly (instead of silently) when the caller provides an input that the underlying C library cannot handle. - Nadeem
29.06.13 18:16, Nadeem Vawda написав(ла):
I ran into the same problem in the _lzma module. My solution was to define a custom converter that does an explicit check before returning the value (see http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134).
Definitely Argument Clinic should use converters for unsigned integers without wraparound by default.
On 06/29/2013 06:24 PM, Serhiy Storchaka wrote:
Definitely Argument Clinic should use converters for unsigned integers without wraparound by default.
Argument Clinic 1.0 is a thin layer over PyArg_ParseTuple. But it will support these sorts of converters, and if people have bright ideas about converters to include in-the-box that's totally fine. but-nothing-has-been-formally-accepted-yet-ly yours, //arry/
participants (5)
-
Guido van Rossum -
Larry Hastings -
Nadeem Vawda -
Serhiy Storchaka -
Victor Stinner