[issue10325] PY_LLONG_MAX & co - preprocessor constants or not?

[Mark Dickinson]

Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report; I agree that there's a potential issue here, and I also think that all these definitions *should* be preprocessor defines.  (Idle question: does C99 require that LONG_MAX and friends are usable in the preprocessor?  I see it in e.g. 7.18.2p2 for INT32_MAX and friends, but I'm not sure if there's something similar for LONG_MAX and co.)

Can you suggest a suitable fix for the PY_ULLONG_MAX and PY_LLONG_MAX defines?  Note that a configure-based fix may need to take into account the special needs of Windows---for which configure isn't used, of course---and OS X---where the same code, based on a single run of configure, should be able to compile to the correct thing both in 32-bit and 64-bit mode, so that universal builds work;  see PC/pyconfig.h and Include/pymacconfig.h respectively for dealing with these issues.

BTW, do you know of any modern non-Windows platforms that don't define LLONG_MIN and LLONG_MAX?  It may well be that the "two's complement" fallback hasn't been exercised in recent years.

> Incidentally, the "two's complement" comment is wrong.
> It also relies on unsigned long long being widest type with no
> padding bits, and -LLONG_MAX-1 not being a trap representation.

Agreed---that comment needs to be better.  I think it's fine, though, for practical purposes to assume an absence of padding bits and no trap representation;  IIRC there are places internally (e.g., in the bitwise operators section of the 'int' type implementation) that already assume two's complement + no padding bits + no trap representation.  (I *thought* I had an old issue open somewhere about documenting---and possibly testing---these assumptions, but now I can't find it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________