On Wed, Jun 26, 2013 at 3:07 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > 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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
