Mark Dickinson <dicki...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to