[PyQt] Qt or PyQt problem?

["V. Armando Solé"]

Phil Thompson wrote:
> On Wed, 03 Jun 2009 22:57:32 +0200, Vicente Sole wrote:
>   
>> createIndex can accept a pointer or a quint32 so, in any case one  
>> would say it is a positive number. Perhaps forcing the return of  
>> internalId() to be a quint64 instead of qint64 in  
>> qabstractitemmodel.sip could do the job, but then we would not be  
>> respecting the (incorrect) Qt API.
>>
>> So, unless I get I successful test under 32-bit with Phil\'s patch, I  
>> would just leave the things as they are.
>>     
>
> Except that this keeps coming up.
>
> Does changing the type of internalId() from qint64 to quint64 solve the
> problem (I don't have a 32 bit Linux system handy)?
>   

No, it does not.

With your patch and changing the returned value of internalId() to 
quint32 I got it working on 32-bit for both cases, that means, when 
passing the object and when passing the address of the object. So, I 
guess internalId() should return an unsigned int32 in a 32-bit platform 
and an unsigned int64 in a 64-bit platform.

Changing qabstractitemmodel.sip from:

qint64 internalId() const;

to

unsigned long internalId() const;

gives correct results for the object case under the platforms I can test.

For the value case, it works under 32-bit but most likely will fail 
under 64-bit when the written number cannot be represented by a 32-bit 
integer.

I do not know if my "unsigned long" patch can have side effects on other 
platforms. It makes sense that if one passes an object and the address 
of the object is stored, one should get back an unsigned of the type the 
machine is using  for addresses. I always thought it is  unsigned long, 
but perhaps there are more exotic solutions around. Is it possible to 
modify qabstractitemmodel.sip set the returned value as quint32 on 
32-bit platforms and quint64 on 64-bit platforms? That should solve the 
issue I am finding without (hopefully) introducing new ones.

Armando