Order of evaluation - aka hidden undefined behaviours.

[Alex Rønne Petersen]

On 26-09-2012 14:04, Timon Gehr wrote:
> 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.

Completely agree with this. Calling convention is irrelevant.

Let us not inherit the C/C++ mess.

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

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org