Order of evaluation - aka hidden undefined behaviours.

[Iain Buclaw]

On 26 September 2012 16:25, David Nadlinger <see at klickverbot.at> wrote:
> On Wednesday, 26 September 2012 at 12:29:38 UTC, Iain Buclaw wrote:
>>
>> On 26 September 2012 13:07, monarch_dodra <monarchdodra at gmail.com> wrote:
>>>
>>> I don't see how the "extern(C)" is involved here, since it is the D
>>> compiler
>>> that first evaluates A(), B() and C() before passing the making the C
>>> function call. Or did I miss something?
>>>
>>
>> There is no physical code generation from the frontend that says
>> "evaluate this".  What it passes to be backend for this operation is a
>> function call. So the backend determines the order of evaluation
>> depending on the order of parameters.
>
>
> I'm not quite sure what you are trying to say here; I guess it depends on
> the definition of "backend". monarch_dodra is right in so far as the effects
> of "extern(C)" are an implementation detail coming from the particular way
> your compiler "glue code" is written; there is no fundamental reason why it
> should be important for parameter evaluation at all.
>

Yes, this is what's done in GDC.  All parameters with side effects
have their result evaluated and saved before calling the extern(D)
functions.

> Speaking of it, what is the reason that the actual order of formal
> parameters (in terms of register allocation/stack layout) is reversed in the
> D calling convention, compared to extern (C) (e.g. on *nix x86_64)?
>

DMD pushes arguments on the stack in reverse order to that of
x86/x86_64.  So it gives the *impression* of LTR evaluation, however,
the parameters themselves aren't actually explicitly evaluated / saved
in temporaries prior to calling.

Regards
-- 
Iain Buclaw

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