On 05-05-2012 12:25, Manu wrote:
On 5 May 2012 11:42, Alex Rønne Petersen <xtzgzo...@gmail.com
<mailto:xtzgzo...@gmail.com>> wrote:
On 05-05-2012 10 <tel:05-05-2012%2010>:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but the question was whether the language guarantees
what I
described. C and C++ don't, and IMO, we should strive to fix
that.
I can't see why it wouldn't, unless the compiler adds in checks and
changes it's behavior or the assembler does it's own quirky
magic. The
bit patterns of how they end up are pretty fixed, it's just how we
interpret them.
It all depends. GCC (and thus GDC) can target very exotic
architectures where any assumptions may not, for whatever reason,
hold true. This is a language design issue more than it's a "how
does architecture X or compiler Y work" issue.
An interesting problem with undefined behavior for integer overflow
and underflow in C/C++ is that optimizers are basically free to do
anything with regards to them, and often do whatever is more
convenient for them.
With regard to code-gen on such colourful architectures, would stating a
defined behaviour for overflow/underflow affect the common case where an
over/underflow did not occur?
Short of an architecture that causes hardware exception on
over/underflow, I suspect that it would interfere with the common case
(additional code generated around every add/sub/etc to handle the
overflow behaviour), and on such an architecture, every single numerical
integer operation would become inefficient.
I don't know of a single architecture (out of the ones on
dlang.org/version.html and many others) that doesn't signal
overflow/underflow somehow (or obey the rules I described in the OP).
I believe this is why C doesn't define the behaviour, because C is still
effectively a macro language, and shouldn't produce 'unexpected'
inefficient code. ('unexpected' from the perspective of the architecture
you're targeting)
Right, but C was designed many, many years ago. :)
I would personally rather see it remain undefined like C, but with
convention approved by common/conventional architectures where cross
platform porting is likely to occur.
Do a grep for "\.min" and "\.max" in Phobos and you'll notice a lot of
places actually depend on the current x86 behavior (wrapping on overflow
and underflow). I don't think we can afford to make the same mistake C
and C++ did.
While I did say that this is a language design issue, it's also a matter
of pragmatism - does any real world architecture that D could possibly
target actually *not* obey the aforementioned rules? I don't know of any
that doesn't.
--
- Alex
