On 1/18/07, Nick Coghlan
Calvin Spealman wrote:
Added a check in test_long.LongTest.test_misc() that long("123\0", 10) fails properly and adapted the patch to int_new to long_new. I get this weird feeling that if its impossible for the function (PyLong_FromString) to know if its being given bad data, having know way to know if the string is supposed to continue past the zero-byte, then doesn't it make sense to say that the function by design is broken?
It makes sense to say the function is being misused in this case - it's designed to convert *C* strings to PyLong objects, so the assumption that there are no embedded NULs is a valid one. That said, I think a better patch for 2.6 would be to provide a separate PyLong_FromPyString function which did the embedded NULL check (and update abstract.c to use that instead of its own internal function).
Thats more or less the route that would make sense to me! If they would be accepted I would gladly provide patches for both int and long types (and float? anything else?). Is there often a usecase that anyone wants to use PyLong_FromString() where the c-string is not the contents of PyString? I suppose when used from extensions creating them.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/