On 1/18/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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 | [EMAIL PROTECTED] | 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/ _______________________________________________ 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
