Order of evaluation - aka hidden undefined behaviours.

[Iain Buclaw]

On 26 September 2012 13:07, monarch_dodra <monarchdodra at gmail.com> wrote:
> On Tuesday, 25 September 2012 at 22:58:11 UTC, Iain Buclaw wrote:
>>
>> Pop quiz!
>>
>> Without cheating, I invite people to have a good guess what 'abc' is equal
>> to, but just to narrow it down.
>>
>> 1)  It isn't "ABC".
>> 2)  On x86/x86_64, it isn't "ACB".
>> 3)  On everything else, it's the reverse of what you'd expect on
>> x86/x86_64.
>
>
> I'd say abc's value is "unspecified", and any attempt at predicting it would
> be bogus. That's my answer anyways
>
>
>> The problem here is that the array operation A[] = B[] + C[] gets
>> transformed into an extern(C) call.  And because there's no strict rules in
>> place over the order of which it's parameters are evaluated, it could go
>> either way (LTR, or RTL).
>
>
> 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.

-- 
Iain Buclaw

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