Closed pokulo closed 10 years ago
on the c++ side it is indeed no problem. I think it is relevant that is negative as at some places there are checks against negative value and as the undefs all fit that scheme they are automatically discared. The i64UNDEF (or the others) go on the c++ side automatically to their complement and remains recognizable this way. We could make the id a signed, still 9e18 possible id's which seems sufficient to me.
I will try to translate quintXX to qintYY whenever iUNDEF is expected in Python API
since most of the UNDEF values are negative , the confusion starts when writing code like this:
since c++ does implicit conversion on compare, this method would return true. The real problem appears, when handling UNDEF values in Python. Because in Python unsigned definitely means no negative values like i64UNDEF also there is no overflow and no implicit conversion. Is the above code safe? How to handle this in python? Or do we make sure, Python never gets quintXX typed UNDEFs?