Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18017 > unrolled thread

Evaluation Order in Function Declaration

Back to article view | Back to comp.lang.c

Contents

  Evaluation Order in Function Declaration Shao Miller <sha0.miller@gmail.com> - 2012-02-28 00:22 -0500
    Re: Evaluation Order in Function Declaration Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-28 10:14 +0100
      Re: Evaluation Order in Function Declaration Kaz Kylheku <kaz@kylheku.com> - 2012-02-28 09:31 +0000
        Re: Evaluation Order in Function Declaration Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-28 13:09 +0100
    Re: Evaluation Order in Function Declaration pete <pfiland@mindspring.com> - 2012-03-08 08:49 -0500

#18017 — Evaluation Order in Function Declaration

Is the evaluation order guaranteed to be left-to-right for the 
declaration of 'baz' in the following code?  Or are the array size 
expressions unsequenced relative to one another, as in 'a + b'?  Or 
something else?

   #include <stdio.h>

   int foo(void) { puts("foo"); return 1; }
   int bar(void) { puts("bar"); return 1; }

   int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }

   int main(void) { return baz(0, 0); }

[toc] | [next] | [standalone]

#18021

Hello,

Am 02/28/2012 06:22 AM, schrieb Shao Miller:
> Is the evaluation order guaranteed to be left-to-right for the
> declaration of 'baz' in the following code?  Or are the array size
> expressions unsequenced relative to one another, as in 'a + b'?  Or
> something else?
> 
>   #include <stdio.h>
> 
>   int foo(void) { puts("foo"); return 1; }
>   int bar(void) { puts("bar"); return 1; }
> 
>   int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
> 
>   int main(void) { return baz(0, 0); }

Yes, not only that it is left to right, you are even allowed to use each
of the preceding identifiers in the expressions. Otherwise things like

double sum(size_t n, size_t m, double A[n][m]) { ... }

could never work reliably.

Jens

[toc] | [prev] | [next] | [standalone]

#18022

On 2012-02-28, Jens Gustedt <jens.gustedt@loria.fr> wrote:
> Hello,
>
> Am 02/28/2012 06:22 AM, schrieb Shao Miller:
>> Is the evaluation order guaranteed to be left-to-right for the
>> declaration of 'baz' in the following code?  Or are the array size
>> expressions unsequenced relative to one another, as in 'a + b'?  Or
>> something else?
>> 
>>   #include <stdio.h>
>> 
>>   int foo(void) { puts("foo"); return 1; }
>>   int bar(void) { puts("bar"); return 1; }
>> 
>>   int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
>> 
>>   int main(void) { return baz(0, 0); }
>
> Yes, not only that it is left to right, you are even allowed to use each
> of the preceding identifiers in the expressions. Otherwise things like
>
> double sum(size_t n, size_t m, double A[n][m]) { ... }
>
> could never work reliably.

Sure they could. The above could mean that A[n][m], n and m independently
receive values from the same sources (the argument expressions). The [n][m]
doesn't have to refer to the values stored in the parameters n, and m
but rather the [n][m] can indicate additional sinks for the data flows
emanating from argument 1 and 2.

Such semantics can be hammered out.  There is no end to how you can lay weasely
traps for the programmer (as the sordid history of this language shows.)

[toc] | [prev] | [next] | [standalone]

#18027

Am 02/28/2012 10:31 AM, schrieb Kaz Kylheku:
> On 2012-02-28, Jens Gustedt <jens.gustedt@loria.fr> wrote:
>> Hello,
>>
>> Am 02/28/2012 06:22 AM, schrieb Shao Miller:
>>> Is the evaluation order guaranteed to be left-to-right for the
>>> declaration of 'baz' in the following code?  Or are the array size
>>> expressions unsequenced relative to one another, as in 'a + b'?  Or
>>> something else?
>>>
>>>   #include <stdio.h>
>>>
>>>   int foo(void) { puts("foo"); return 1; }
>>>   int bar(void) { puts("bar"); return 1; }
>>>
>>>   int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
>>>
>>>   int main(void) { return baz(0, 0); }
>>
>> Yes, not only that it is left to right, you are even allowed to use each
>> of the preceding identifiers in the expressions. Otherwise things like
>>
>> double sum(size_t n, size_t m, double A[n][m]) { ... }
>>
>> could never work reliably.
> 
> Sure they could. The above could mean that A[n][m], n and m independently
> receive values from the same sources (the argument expressions). The [n][m]
> doesn't have to refer to the values stored in the parameters n, and m
> but rather the [n][m] can indicate additional sinks for the data flows
> emanating from argument 1 and 2.

theoretically they could. pratically the standard says that the
identifier n for example is visible for the declaration of A

> Such semantics can be hammered out.  There is no end to how you can lay weasely
> traps for the programmer (as the sordid history of this language shows.)

sure, I just don't see how your comment is related to the question
Shao had and how with any respect it would be helpful. You seem to
find it necessary to rant against VLA in any form you see them. Not
very helpful for anybody, probably not even for yourself.

Jens

[toc] | [prev] | [next] | [standalone]

#18326

Shao Miller wrote:
> 
> Is the evaluation order guaranteed to be left-to-right for the
> declaration of 'baz' in the following code?  Or are the array size
> expressions unsequenced relative to one another, as in 'a + b'?  Or
> something else?
> 
>    #include <stdio.h>
> 
>    int foo(void) { puts("foo"); return 1; }
>    int bar(void) { puts("bar"); return 1; }
> 
>    int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
> 
>    int main(void) { return baz(0, 0); }

Whether that program will output "foo" or "bar" first,
is unspecified.

n1570

6.5.2.2 Function calls

12 EXAMPLE In the function call
  (*pf[f1()]) (f2(), f3() + f4())
   the functions f1, f2, f3, and f4 may be called in any order.
   All side effects have to be completed before
   the function pointed to by pf[f1()] is called.

-- 
pete

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web