Order of evaluation - aka hidden undefined behaviours.

[Iain Buclaw]

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?

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.