[Python-checkins] CVS: python/dist/src/Lib/test test_descr.py,1.114,1.115

[Guido van Rossum]

> [Guido]
> > Due to the bizarre definition of _PyLong_Copy(), creating an instance
> > of a subclass of long with a negative value could cause core dumps
> > later on.  Unfortunately it looks like the behavior of _PyLong_Copy()
> > is quite intentional, so the fix is more work than feels comfortable.
> 
> What specifically is bizarre?  Looks to me like _PyLong_Copy() is plain
> wrong, and I probably wrote it <wink>.
> 
> 		result->ob_size = i;
> 
> should be
> 
> 		result->ob_size = src->ob_size;
> 
> if I'm guessing what bizarre means to you.
> 
> Is that what you mean, or something else?

I had misread the code and thought that long_pos() was depending on
this property.  But it isn't -- I somehow confused long_pos and
long_abs.

So thanks for fixing this.

> The bizarreness *begins* with that _longobject fakes a
> PyObject_VAR_HEAD header by hand, then abuses the ob_size member to
> store the sign bit of the long as well as the number of bytes.  So I
> expect there was more than one bug here (and that _PyLong_Copy() is
> one of them).

I have half a feeling that the header was explicitly not using
VAR_HEAD because it isn't quite a standard variable size object.  But
since PyLong_Type sets tp_itemsize, it really should be defined a
variable size object.  I wonder if there could be places where the
assumption ob_size >= 0 is made.  (I checked _PyObject_GetDictPtr()
and it correctly checks for tsize < 0.)

--Guido van Rossum (home page: http://www.python.org/~guido/)