Robert Jacques wrote:
So by the spec (and please correct me if I'm reading this wrong)
g = e + f => g = cast(long)( cast(integer)e + cast(integer)f );
where integer is unbounded in bits (and therefore has no overflow)
therefore
g = e + f; => d = cast(long) e + cast(long) f;
is more in keeping with the spec than
g = cast(long)(e+f);
in terms of a practical implementation, since there's less possibility
for overflow error.
The spec leaves a lot of room for implementation defined behavior. But
still, there are common definitions for those implementation defined
behaviors, and C programs routinely rely on them. Just like the C
standard supports 32 bit "bytes", but essentially zero C programs will
port to such a platform without major rewrites.
Silently changing the expected results is a significant problem. The guy
who does the translation is hardly likely to be the guy who wrote the
program. When he notices the program failing, I guarantee he'll write it
off as "D sux". He doesn't have the time to debug what looks like a
fault in D, and frankly I would agree with him.
I have a lot of experience with people porting C/C++ programs to Digital
Mars compilers. They run into some implementation-defined issue, or rely
on some bug in B/M/X compilers, and yet it's always DM's problem, not
B/M/X or the code. There's no point in fighting that, it's just the way
it is, and to deal with reality means that DM must follow the same
implementation-defined behavior and bugs as B/M/X compilers do.
For a C integer expression, D must either refuse to compile it or
produce the same results.
(Caveat: most 32-bit compilers probably defaulted integer to int, though
64-bit compilers are probably defaulting integer to long.)
All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are
setting int at 32 bits for sensible compatibility reasons.
