Sorry this was posted on the wrong newsgroup so I am posting it here!

On 17/01/2022 03:00, Satan wrote:
> I read somewhere that the parameters of functions are evaluated right >>
> to left but it all depends on the compiler. Therefore, does this mean
> that the output of this program is "undefined" meaning there is no
> definite answer!
>
> #include <stdio.h>
>
> void fun(int, int);
>
> int main()
> {
> int i = 5;
> fun(--i, i++);
> fun(++i, i--);
> printf("From Main: %d\n", i++);
>
> return 0;
> }
>
> void fun(int x, int y)
> {
> printf("From Function: %d %d\n", x++, y--);
> }
>

On 1/16/22 10:39 PM, Satan wrote:
> Sorry this was posted on the wrong newsgroup so I am posting it here!
>
>
> On 17/01/2022 03:00, Satan wrote:
>> I read somewhere that the parameters of functions are evaluated right >>
>> to left but it all depends on the compiler. Therefore, does this mean
>> that the output of this program is "undefined" meaning there is no
>> definite answer!
>>
>> #include <stdio.h>
>>
>> void fun(int, int);
>>
>> int main()
>> {
>> int i = 5;
>> fun(--i, i++);
>> fun(++i, i--);
>> printf("From Main: %d\n", i++);
>>
>> return 0;
>> }
>>
>> void fun(int x, int y)
>> {
>> printf("From Function: %d %d\n", x++, y--);
>> }
>>
>
>
>
>

Yes, there is no sequencing between the evaluation of the various
parameters to the function, to those calls invoke undefined behavior.

Implementations might give additional promises, but that is beyond the
control of the standard, and there may be a 'normal' order they follow,
but that still doesn't make it a requirement, and you might get burned
by a case where the implementation did it different in some case because
of ...reasons... so do go by what seems to work.

Remember, doing what you expected is perfectly fine possible undefined
behavior, but you shouldn't count on it.

On 1/16/22 10:39 PM, Satan wrote:
> Sorry this was posted on the wrong newsgroup so I am posting it here!
>
>
> On 17/01/2022 03:00, Satan wrote:
>> I read somewhere that the parameters of functions are evaluated right >>
>> to left but it all depends on the compiler. Therefore, does this mean
>> that the output of this program is "undefined" meaning there is no
>> definite answer!
>>
>> #include <stdio.h>
>>
>> void fun(int, int);
>>
>> int main()
>> {
>> int i = 5;
>> fun(--i, i++);
>> fun(++i, i--);
>> printf("From Main: %d\n", i++);
>>
>> return 0;
>> }
>>
>> void fun(int x, int y)
>> {
>> printf("From Function: %d %d\n", x++, y--);>> }

"Except as specified later, side effects and value computations of
subexpressions are unsequenced." (6.5p3).

The description of function call expressions is "later", but does not
specify the sequencing of the argument sub-expressions relative to each
other, so they are unsequenced. That doesn't matter for your printf()
calls. However, it does matter for your calls to fun().

"If a side effect on a scalar object is unsequenced relative to either a
different side effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined. If
there are multiple allowable orderings of the subexpressions of an
expression, the behavior is undefined if such an unsequenced side effect
occurs in any of the orderings." (6.5p2).

`i` is a scalar object, and both of your calls to fun() involve two
different sub-expressions with side effects on `i`, and there are
multiple permitted orderings of those sub-expressions, so the behavior
of your code is undefined.

`undefined behavior` is a much stronger statement than "unspecified". It
means that the C standard imposes NO requirements on the behavior of
your program.

On 17/01/2022 04:39, Satan wrote:
> Sorry this was posted on the wrong newsgroup so I am posting it here!
>
>
> On 17/01/2022 03:00, Satan wrote:
>> I read somewhere that the parameters of functions are evaluated right >>
>> to left but it all depends on the compiler. Therefore, does this mean
>> that the output of this program is "undefined" meaning there is no
>> definite answer!
>>

Your conclusion is correct, but the reasoning is slightly wrong.

First, the order of evaluation of parameters to a function is
"indeterminately sequenced". (As is the function identifier itself,
which could be a function pointer.)

So if you have "foo(A, B)", then the compiler must either evaluate "A"
before evaluating "B", or evaluate "B" before evaluating "A". It can
pick either. It doesn't even have to have a fixed order in the code -
it could swap the orders between different calls. But logically it has
to do one completely before doing the other. (As always, the compiler
can generate mixtures of the evaluations as long as the results match
the logical requirements.)

Some more limited compilers have fixed evaluation order of function
parameters. More optimising compilers will choose whatever works best
at the time.

But it is not the unspecified ordering of evaluation of the arguments
that is the problem in your code. It is a matter of "sequence points".
These can be thought of as barriers in the code - logically, when the
code hits a sequence point, everything before it must be finished and
then you can start on everything after it. The end of a statement is a
sequence point - so for "i++; i--;" the increment has to be completed
before the decrement can be done, and everything works out safely.

There is no sequence point between evaluating the arguments of a function.

Between sequence points, you are limited in what you can do as the state
of the program has to be consistent. For any given object, you can
either write to it once, or read from it (as often as you like) - you
can't do both, and you can't write more than once. This makes sense if
you think about it.

("++i" is treated as "(i += 1)" or "(i = i + 1)", and there is a
sequence pointer at the assignment operator.)

So the trouble with "fun(--i, i++);" is /not/ a matter of which function
argument is evaluated first. It is that you are mixing multiple reads
and writes to "i" without a clear ordering - and that is undefined
behaviour.

Note that "undefined behaviour" does not just mean there is no definite
answer - it means that /anything/ can happen. It's not just a matter of
getting different integers printed when using different compilers
(though that's the most likely outcome) - maybe you'll get nothing at
all, or a crash, or demons will fly out of your nose. Trying to execute
undefined behaviour is a really bad thing!

>> #include <stdio.h>
>>
>> void fun(int, int);
>>
>> int main()
>> {
>> int i = 5;
>> fun(--i, i++);
>> fun(++i, i--);
>> printf("From Main: %d\n", i++);
>>
>> return 0;
>> }
>>
>> void fun(int x, int y)
>> {
>> printf("From Function: %d %d\n", x++, y--);
>> }
>>
>
>
>
>

David Brown <david.brown@hesbynett.no> writes:

> ("++i" is treated as "(i += 1)" or "(i = i + 1)", and there is a
> sequence pointer at the assignment operator.)

No, there is no sequence point at assignment.

--
Ben.

On 17/01/2022 13:36, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> ("++i" is treated as "(i += 1)" or "(i = i + 1)", and there is a
>> sequence pointer at the assignment operator.)
>
> No, there is no sequence point at assignment.
>

Re-reading the section in the standards, I stand corrected. Thank you.

I am trying to understand 6.5p2 here:

"""
If a side effect on a scalar object is unsequenced relative to either a
different side effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined. If
there are multiple allowable orderings of the subexpressions of an
expression, the behavior is undefined if such an unsequenced side effect
occurs in any of the orderings. 85)
"""

The footnote says that this allows expressions like "i = i + 1;" while
rendering undefined "i = ++i + 1;".

(If there had been a sequence point at assignment, then this second
statement would have had defined behaviour.)

But in "i = i + 1;", the store to "i" is a side-effect on "i". The
calculation "i + 1" is a value computation using the same scalar object.
With no sequence point, these are unsequenced - and therefore
undefined. What am I missing?

On Monday, 17 January 2022 at 16:26:22 UTC+2, David Brown wrote:
> On 17/01/2022 13:36, Ben Bacarisse wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> ("++i" is treated as "(i += 1)" or "(i = i + 1)", and there is a
> >> sequence pointer at the assignment operator.)
> >
> > No, there is no sequence point at assignment.
> >
> Re-reading the section in the standards, I stand corrected. Thank you.
>
> I am trying to understand 6.5p2 here:
> """
> If a side effect on a scalar object is unsequenced relative to either a
> different side effect on the same scalar object or a value computation
> using the value of the same scalar object, the behavior is undefined. If
> there are multiple allowable orderings of the subexpressions of an
> expression, the behavior is undefined if such an unsequenced side effect
> occurs in any of the orderings. 85)
> """
>
> The footnote says that this allows expressions like "i = i + 1;" while
> rendering undefined "i = ++i + 1;".
>
> (If there had been a sequence point at assignment, then this second
> statement would have had defined behaviour.)
>
> But in "i = i + 1;", the store to "i" is a side-effect on "i". The
> calculation "i + 1" is a value computation using the same scalar object.
> With no sequence point, these are unsequenced - and therefore
> undefined. What am I missing?

Hmm? As neither i nor i + 1 changes value of i these can be evaluated
unsequenced, yet the outcome of i = i + 1 will be still always same as
assignment itself can happen only after both have been evaluated.

On 1/17/22 9:26 AM, David Brown wrote:
> On 17/01/2022 13:36, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> ("++i" is treated as "(i += 1)" or "(i = i + 1)", and there is a
>>> sequence pointer at the assignment operator.)
>>
>> No, there is no sequence point at assignment.
>>
>
> Re-reading the section in the standards, I stand corrected. Thank you.
>
> I am trying to understand 6.5p2 here:
>
> """
> If a side effect on a scalar object is unsequenced relative to either a
> different side effect on the same scalar object or a value computation
> using the value of the same scalar object, the behavior is undefined. If
> there are multiple allowable orderings of the subexpressions of an
> expression, the behavior is undefined if such an unsequenced side effect
> occurs in any of the orderings. 85)
> """
>
> The footnote says that this allows expressions like "i = i + 1;" while
> rendering undefined "i = ++i + 1;".
>
> (If there had been a sequence point at assignment, then this second
> statement would have had defined behaviour.)
>
> But in "i = i + 1;", the store to "i" is a side-effect on "i". The
> calculation "i + 1" is a value computation using the same scalar object.
> With no sequence point, these are unsequenced - and therefore
> undefined. What am I missing?

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator." (6.5p1).

assignment:
"The side effect of updating the stored value of the left operand is
sequenced after the value computations of the left and right operands."
(6.5.16).

prefix increment and decrement:
"The expression ++E is equivalent to (E+=1)" (6.5.3.1p2). Therefore, per
6.5.16, the value computation is sequenced before the side effect of
updating the stored value.

A: value computation of ++i
B: update to value of i due to ++i
C: value computation of +
D: update to value of i due to =

A is sequenced before both B and C, and C is sequenced before D.
However, B is not sequenced relative to both C and D. Being unsequenced
relative to D is what renders the behavior undefined.

On 1/17/22 2:46 AM, David Brown wrote:
....
> First, the order of evaluation of parameters to a function is

I think you mean "arguments" rather than "parameters".

> "indeterminately sequenced". (As is the function identifier itself,
> which could be a function pointer.)

"Except as specified later, side effects and value computations of
subexpressions are unsequenced." (6.5p3). The description of Function
calls (6.5.2.2) specifies that there is a sequence point separating
evaluation of the function designator and the function arguments from
the evaluation of the function call itself, but says nothing about the
sequencing of the function designator and the arguments relative to each
other, so 6.5p3 applies to those.

This matters because evaluations that are unsequenced can be
interleaved, but evaluations that are indeterminately sequenced cannot
be be interleaved (footnote 13).

Evaluations in a calling function can be indeterminately sequenced
relative to the called function (6.5.2.2p10), and evaluations in an
initializer list are indeterminately sequenced relative to each other
(6.7.9p23). In all other cases, evaluations are either sequenced or
unsequenced relative to each other, but never indeterminately sequenced.