Mark Dickinson wrote:
> Question: should the CPython source compile cleanly and work
> correctly on (mostly ancient or hypothetical) machines that use
> ones' complement or sign-and-magnitude to represent signed integers?
I think that's the wrong question to ask. What you really meant to ask
(IIUC) is this: Should CPython be allowed to invoke behavior that is
declared undefined by the C standard, but has a clear meaning when
assuming two's complement?
This is different from your question, by taking into account that
compilers may perform optimization based on the promises of the C
standard.
For example, compiling
int f(int a)
{
if (a+1>a)
return 6;
else
return 7;
}
with gcc 4.3.4, with -O2 -fomit-frame-pointer, compiles this
to
f:
movl $6, %eax
ret
IOW, the compiler determines that the function will always
return 6 (*). If you assume that the int type is guaranteed
in two's complement, then the generated code would be wrong
(and Python would not work correctly).
So this isn't about unrealistic and outdated hardware, but about
current and real problems. Therefore, I don't think we should make
assumptions beyond what standard C guarantees.
Regards,
Martin
(*) If you wonder why the gcc behavior is conforming to C:
if a+1 does not overflow, it will be indeed greater than a,
and the result is 6.
If a+1 does overflow, undefined behavior occurs, and the
program may do whatever it desires, including returning 6.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
