Order of evaluation - aka hidden undefined behaviours.

[Timon Gehr]

On 09/26/2012 10:11 AM, Walter Bright wrote:
> 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.

On x86. It is unspecified, therefore different compilers on different
architectures do it in different ways.

> So we should be all right by simply
> defining that D do it that way for C functions.
>

I disagree. Why should the calling convention have an impact on code
semantics? The code reads LTR, therefore evaluation should consistently
be LTR.

> 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.
> ...

There is no such thing. C and C++ get evaluation order thoroughly wrong.