On 18 December 2012 21:31, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
On 12/18/12 11:58 AM, Iain Buclaw wrote:
On 18 December 2012 16:43, Peter Alexander <peter.alexander.au@gmail.com
<mailto:peter.alexander.au@gmail.com>> wrote:

    On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:

        Should we take this as an opportunity for other compiler
        maintainers to implement their own compiler-specific predefined
        attributes?


    Please, no!

    Suppose GDC implements @noreturn (or whatever other attribute)

    Later, LDC implements @noreturn separately with slightly different
    semantics.

    We now end up in a situation where @noreturn cannot be used
    portably, and neither compiler developer has incentive to change
    (whoever changes breaks their users code).


Provide a situation where @noreturn attribute would mean anything other
than telling the compiler to assume that the function|| cannot return,
and I might please you on *that* particular attribute.

One possibility: one compiler assumes @noreturn never returns, whereas another enforces that by adding an HLT at the end of the function.

Andrei



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.

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.

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';