<div class="gmail_extra"><div class="gmail_quote">On 5 May 2012 11:42, Alex Rønne Petersen <span dir="ltr"><<a href="mailto:xtzgzorex@gmail.com" target="_blank">xtzgzorex@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On <a href="tel:05-05-2012%2010" value="+358505201210" target="_blank">05-05-2012 10</a>:23, Era Scarecrow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, but the question was whether the language guarantees what I<br>
described. C and C++ don't, and IMO, we should strive to fix that.<br>
</blockquote>
<br>
I can't see why it wouldn't, unless the compiler adds in checks and<br>
changes it's behavior or the assembler does it's own quirky magic. The<br>
bit patterns of how they end up are pretty fixed, it's just how we<br>
interpret them.<br>
</blockquote>
<br></div>
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.<br>

<br>
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.</blockquote>
<div><br></div><div>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?</div><div>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.</div>
<div><br></div><div>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)</div>
<div><br></div><div>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.</div></div></div>