Order of evaluation - aka hidden undefined behaviours.

[Walter Bright]

On 9/26/2012 12:36 AM, Iain Buclaw wrote:
> On Tuesday, 25 September 2012 at 23:39:39 UTC, Walter Bright wrote:
>> On 9/25/2012 3:58 PM, Iain Buclaw wrote:
>>> 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).
>>>
>>> Serious note: This test is bogus as this and similar other failing tests on
>>> non-x86 platforms are not at all obvious to the users who get issues. So what
>>> are we to do about it?
>>
>> D needs to move towards a defined order of evaluation. I understand that
>> there's a problem when using parts of a C compiler that feels free to reorder
>> within the C rules. It's something we have to deal with sooner or later, by
>> either:
>>
>> 1. adjusting the C optimizer so it follows D rules for D code
>>
>> 2. assigning terms to temporaries that are executed in a specific order by C
>> rules
>
>
> Indeed, but where does that leave code that gets compiled down to a extern(C) call?

C functions all seem to evaluate their args right-to-left, even though the C 
Standard doesn't specify that. So we should be all right by simply defining that 
D do it that way for C functions.

It doesn't actually matter what order D does things, we just have to pick one. 
And so we might as well pick one that C compilers naturally do anyway.

>
> eg, in the OP, the following is generated:
> _arraySliceSliceAddSliceAssign_f(A[], C[], B[]);
>
> To say that all extern(C) calls must follow D rules for D code (LTR evaluation),
> is to change the current behaviour of array operations on it's head, so we'll
> have to correct a whole lotta changes in code generation to alter the order of
> parameters, and ensure that both DRT supplied and internally generated functions
> are corrected for this.
>
> Well... someone's got to do the grizzly bits that no one else wants to do. :~)
>
>
> Regards,
> Iain.