Lisandro Dalcin wrote: > > This is the Pyrex algorithm: > > if type1.rank < type2.rank: > widest_type = type2 > elif type1.rank > type2.rank: > widest_type = type1 > elif type1.signed < type2.signed: > widest_type = type1 > else: > widest_type = type2 > > Below I pasted what the C standard says... IIUC, Pyrex does not follow > it, right?
I'm trying to do the best I can. > Otherwise, if the type of the operand with signed integer type can represent > all of the values of the type of the operand with unsigned integer type, then > the operand with unsigned integer type is converted to the type of the > operand with signed integer type. This is the part that neither Pyrex nor Cython can follow exactly, because it requires knowning the actual sizes of the types. E.g. if int and long are the same size, then unsigned int + long should be unsigned long, because signed long can't represent all the values of unsigned int. But if long is wider than int, then it can, so the result should be signed long. > Pyrex: <unsigned int> + <long> --> <long> > Cython: <unsigned int> + <long> --> <unsigned long> In other words, Pyrex is guessing that long is wider than int, which will sometimes be wrong. But Cython seems to be guessing that anything unsigned is at least as wide as anything signed, which seems less likely to be right to me. The only guaranteed correct thing to do would be to treat the result as being of unknown signedness in these cases, and to refuse to do anything with it that would require knowing the signedness (e.g. choosing which Python conversion function to call). I might consider doing that in a future version. -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
