Order of evaluation - aka hidden undefined behaviours.

Iain Buclaw ibuclaw at ubuntu.com
Wed Sep 26 10:18:07 PDT 2012


On 26 September 2012 16:10, Alex Rønne Petersen <alex at lycus.org> wrote:
> On 26-09-2012 13:45, Iain Buclaw wrote:
>>
>> On Wednesday, 26 September 2012 at 08:12:16 UTC, 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. 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.
>>>
>>
>> Speaking as a generalisation, no that is not true.  C functions for
>> x86/x86_64 all seem to evaluate their args right-to-left. However - and
>> this may be different from compiler to compiler - GCC at least does
>> left-to-right evaluation for everything else (ARM, SPARC, etc) because
>> that is the order that arguments are pushed onto the stack for those
>> architecture backends.
>>
>> If right-to-left should be the strict standard to follow for extern(C),
>> then document this behaviour as part of the specification, and I'll
>> implement it. :~)
>>
>> Regards
>> Iain
>
>
> There is a pull request that does this, but it has not yet been merged
> because it's waiting on compilers to catch up... ;)
>

Got a link? :~)

-- 
Iain Buclaw

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


More information about the Digitalmars-d mailing list