<div class="gmail_extra"><div class="gmail_quote">On 18 December 2012 21:31, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</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 12/18/12 11:58 AM, Iain Buclaw wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 18 December 2012 16:43, Peter Alexander <<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@<u></u>gmail.com</a>>> wrote:<br>
<br>
    On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:<br>
<br>
        Should we take this as an opportunity for other compiler<br>
        maintainers to implement their own compiler-specific predefined<br>
        attributes?<br>
<br>
<br>
    Please, no!<br>
<br>
    Suppose GDC implements @noreturn (or whatever other attribute)<br>
<br>
    Later, LDC implements @noreturn separately with slightly different<br>
    semantics.<br>
<br>
    We now end up in a situation where @noreturn cannot be used<br>
    portably, and neither compiler developer has incentive to change<br>
    (whoever changes breaks their users code).<br>
<br>
<br></div><div class="im">
Provide a situation where @noreturn attribute would mean anything other<br>
than telling the compiler to assume that the function|| cannot return,<br>
and I might please you on *that* particular attribute.<br>
</div></blockquote>
<br>
One possibility: one compiler assumes @noreturn never returns, whereas another enforces that by adding an HLT at the end of the function.<span class="HOEnZb"><font color="#888888"><br>
<br>
Andrei<br>
<br>
</font></span></blockquote></div><br><br>The effect would really be the same though.  Typically in a @noreturn function, there is no 'ret', so if the function were to return, the stack would be left corrupt.  The key difference is that whilst in one program, it halts at the point of the program that should never be reached.  The other crashes an burns with a HLT or SEGV shortly afterwards.<br>
<br>This behaviour I describe incidentally is the case with assert(0) in release code right now.  Different compilers handle it differently, DMD just so happens to enforce that by adding a HTL at the end whilst others don't.<br clear="all">
<br>-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</div>