[PyQt] Bug in QAbstractItemModel::createIndex()?

[Phil Thompson]

On Friday 06 April 2007 10:10 am, Andreas Pakulat wrote:
> On 06.04.07 08:41:26, Phil Thompson wrote:
> > On Thursday 05 April 2007 11:25 pm, Andreas Pakulat wrote:
> > > On 05.04.07 22:24:58, Phil Thompson wrote:
> > > > On Thursday 05 April 2007 6:42 pm, Andreas Pakulat wrote:
> > > > > Tried printfs and fprintfs (to stderr), but I don't see anything
> > > > > when running the python application... sip+PyQt4 is built in debug
> > > > > mode, do I need to do something else?
> > > >
> > > > No - assuming you've put them in the right place and installed it.
> > >
> > > I've put them into the first block of
> > > meth_QAbstractItemModel_createIndex() and did a make install
> > > afterwards....
> > >
> > > Ok, now it gets interesting I think. It doesn't hit the int-block in
> > > that method, it hits the object block, so when doing
> > >
> > > self.createIndex(parentItem.row(), 0, id(parentItem))
> > >
> > > the function that determines the parameters thinks the 3rd one is an
> > > object, not an integer.
> >
> > Put a printf() in parsePass1() in siplib.c in the 'i' branch of the big
> > switch statement. We want to know what exception was raised (ie. when the
> > call to PyErr_Occurred() succeeded).
>
> I've put an PyErr_Print(); into the if-part and here's the output (the
> object parsing block is printed when in QtCore the 2nd block with the
> pointer is executed). So as far as I can see the problem is that id()
> returns a long int, but its going to be converted to an int and that
> fails...
>
> emodel>python simpletreemodel.py
> ....
> -------------------------
> OverflowError: long int too large to convert to int
> -------------------------
> Object parsing block
> -------------------------
> OverflowError: long int too large to convert to int
> -------------------------
> Object parsing block
> -------------------------
> OverflowError: long int too large to convert to int
> -------------------------
> Object parsing block

And I guess if you change the call to PyLong_AsLong() instead of 
PyInt_AsLong() then it would call the right overload.

So the question is...

Should SIP quietly lose the extra bits, or should it raise an exception.

At this stage of the development cycle (with a new release imminent) I'm not 
comfortable with introducing bounds checking on int/short/char types. If it's 
seen to be a good thing then it can be added in a later version.

Phil