Nick> With an explicit base, however, PyLong_FromString is called
Nick> directly. Since that API takes a char* string, it stops at the
Nick> first embedded NULL:
>>>> long('123\0003', 10)
Nick> 123L
>>>> long('123\00032', 10)
Nick> 123L
Nick> So 'long_from_string' in abstract.c already has this problem
Nick> solved - the helper function just needs to be moved into
Nick> longobject.c so it can be used for explicit bases as well.
That's a bug. \0 is not a numeric character in any base, so the docs imply
that an exception should be raised:
long([x[, radix]])
Convert a string or number to a long integer. If the argument is a
string, it must contain a possibly signed number of arbitrary size,
possibly embedded in whitespace. The radix argument is interpreted in
the same way as for int(), and may only be given when x is a
string. Otherwise, the argument may be a plain or long integer or a
floating point number, and a long integer with the same value is
returned. Conversion of floating point numbers to integers truncates
(towards zero). If no arguments are given, returns 0L.
The only nonnumeric characters which can occur are whitespace characters,
and they can only occur at the start or end of the string. Unlike the
similar C functions atoi and atof conversion doesn't just continue until a
nonnumeric character is encountered. There is no way to tell the caller
that part of the string wasn't munched.
Skip
_______________________________________________
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
