[Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names

Gisle Aas gisle@ActiveState.com
23 Jun 2000 20:31:09 +0200


Jeremy Hylton <jeremy@beopen.com> writes:

> Do you have a pure-Python test case that causes the new code to be
> executed?

No.  If I call the python level getattr() then it will demand that the
second argument is a string.  This is probably also the reason this
has not been a problem for "normal" people.

But, if I mix some perl into this (using an unpatched python):

  >>> import perl
  >>> hasattr = perl.eval("sub { shift->HasAttr(shift) }")
  >>> hasattr
  <perl CODE(0x80f0e50) ref at 80f3ec8>
  >>> hasattr({}, "keys")  
  1
  >>> hasattr({}, "foo")
  0
  >>> hasattr({}, 42)
  Segmentation fault

I could of course make the perl interface to HasAttr() also demand a
string as name argument before passing it on to PyObject_HasAttr, but
the current proposed patch looked more right to me.

An alternative could be to patch the api documentation to say that the
name argument to these functions has to be PyString objects.  You
might then even consider changing the prototypes to be like this:

   int PyObject_HasAttr(PyObject *v, PyStringObject* name);

Regards,
Gisle