QModelIndex::internalID and QAbstractItemModel::createIndex type mismatch?

QModelIndex::internalID returns qint64 but QAbstractItemModel::createIndex takes quint32 as parameter. I found this to be a little confusing. Is part of internal id reserved by Qt or is this a bug?

It does seem odd. "Is it a bug?" depends on whether it was done that way on purpose. The internal ID is just the void* internal pointer cast to an integer. So I guess internalId returns a 64-bit integer to allow for platforms with 64-bit pointers. Why the createIndex parameter should be 32-bit I don't know... backward compatibility perhaps?

What I think is a bug is that QModelIndex::internalId does this: return reinterpret_cast<qint64>(p); On a platform with 32-bit pointers this casts a 32-bit value to a 64-bit value, and I don't think the result is properly defined.

I used the internal ID to store a negative value, and the value I got back from QModelIndex::internalId was compiler-dependant. Visual C++ (Windows) and gcc (Linux) gave me back my original negative value in 64-bit form (I guess they first reinterpreted the 32-bit pointer as an int32 and then promoted it to an int64: 0xFFFFFFFF -> 0xFFFFFFFFFFFFFFFF). Sun Studio (Solaris) took the 32-bit value and left-padded with zeros, giving me back a completely different number (0xFFFFFFFF -> 0x00000000FFFFFFFF).

You might say I shouldn't have passed a signed value to a function that takes a uint32; but the same problem would affect a 32-bit unsigned value with a high-bit of 1.

I don't think it is a bug, might be some portability workaround. I don't see any problem with this, I have used this earlier.

You can either store a void* or quint32, just forget about the implementation...If you want to store void * use internalPointer(), else use internalID(), you should not have any problems as long as don't mix the usage.

Addresses are supposed to be positive numbers. And quint32 and qint64 are promised to be 32 bit and 64 bit respectively on all supported platforms by qt. So you cannot run into trouble because of this. As of use, I have used many many times with no problems.