[Python-Dev] Re: [Bug #121013] Bug in
Tue, 28 Nov 2000 12:12:56 +0100
Michael Hudson wrote:
> > Since not using PySequence_Fast() to initialize the protocol,
> > I'd suggest doing a Py_FatalError() with some explanatory
> > text which gets printed to stderr -- still better than a
> > segfault at some later point due to some dangling pointers...
> So you'd want PySequence_Fast_GETITEM to look like
> #define PySequence_Fast_GETITEM(s,i) \
> (PyList_Check((s)) ? PyList_GET_ITEM((s),(i)) : \
> (PyTuple_Check((s))? PyTuple_GET_ITEM((s),(i)) : \
> Py_FatalError("muffin!") ))
> ? That'd probably be fair - you'd want to check any performance hit, but
> I wouldn't be surprised if it was neglible.
> [Fredrik's PySequence_Fast_* APIs]
> > I think Fredrik speculated on having the compiler optimizers
> > taking care of the check...
> gcc 2.95.1 doesn't seem to - even with -O9 you get stuff like
> .stabn 68,0,825,.LM312-string_join
> movl PyList_Type@GOT(%ebx),%eax
> cmpl %eax,4(%edi)
> jne .L875
> movl 12(%edi),%eax
> jmp .L898
> .p2align 4,,7
> leal 12(%edi),%eax
> movl -32(%ebp),%edx
> movl (%eax,%edx,4),%esi
> ... but I'm no expert in assembly reading.
> > hmm, it would probably also help
> > to somehow declare PyTypeObject slots "const" -- is this possible
> > in a struct definition ?
> I have no idea!
Me neither -- it could help the compiler when moving type
checks out of inner loops: the type slot of PyObject normally
doesn't change (except on Windows where you have to patch it
in order make VC++ happy).
Anyone got a working idea in this direction ?
Python Pages: http://www.lemburg.com/python/