What does f(x++) mean?

[becte]

What does the standard say about f(x++) ?
1. x is incremented and then the that value is
used in function f, i.e. x++; f(x);
2. the value of x (before ++) is send to f and
after returning. x is increased, i.e f(x); x++;
3. undefined behavior, it is different for different compilers

I encountered the problem when I was porting code (not written by me)
from AIX to Linux. Visual age and gcc gave different results (2 and 1
respectively), so I had to manually change f(x++); to f(x); x++
in a lot of places because f(x++) was frequently used.

[Sheldon Simms]

On Fri, 03 Oct 2003 07:07:41 -0700, becte wrote:

What does the standard say about f(x++) ?
1. x is incremented and then the that value is
used in function f, i.e. x++; f(x);
2. the value of x (before ++) is send to f and
after returning. x is increased, i.e f(x); x++;
3. undefined behavior, it is different for different compilers

I encountered the problem when I was porting code (not written by me)
from AIX to Linux. Visual age and gcc gave different results (2 and 1
respectively), so I had to manually change f(x++); to f(x); x++
in a lot of places because f(x++) was frequently used.
I just happened to read a similar question yesterday in google,
dating from 1982. Dennis Ritchie replied:
From: research!dmr
Date: Mon Dec 27 06:19:21 1982
Subject: Pure and applied C

John Levine wondered whether, in the call bar(x++) with x global,
bar would see the old or the incremented value of x. The parameter
is clearly the old value; the question is whether the compiler might
be allowed to do the increment after the call. ... Steve Johnson brought up this very
point when he was writing PCC, and I said that as far as I knew he was
entitled to delay the increment. We agreed, though, that the result
might surprise people, and he decided not to rock the boat.

As for today, 6.5.2.4.2 states

The result of the postfix ++ operator is the value of the operand.

so, the value passed as an argument to f() should definitely be
the value before incrementing.

6.5.2.4.2 continues:

The side effect of updating the stored value of the operand shall
occur between the previous and the next sequence point.

That combined with C.1:

The following are the sequence points described in 5.1.2.3:
-- The call to a function, after the arguments have been evaluated.
Seems to indicate that the value of x must be updated before the
f() is called, not after, as you claim in (2). I compiled a test
program with GCC (3.3.1) to investigate its behavior:

#include <stdio.h>

int x = 0;

void f (int y)
{
printf("global in function: %d\n", x);
printf("param in function: %d\n", y);
}

int main (void)
{
printf("before function: %d\n", x);
f(x++);
printf("after function: %d\n", x);
return 0;
}
The results were:

before function: 0
global in function: 1
param in function: 0
after function: 1

- Sheldon

[Simon Biber]

"becte" <he***************@hotmail.com> wrote:

What does the standard say about f(x++) ?
1. x is incremented and then the that value is
used in function f, i.e. x++; f(x);
Absolutely wrong. This would be a preincrement effect, not postincrement.
2. the value of x (before ++) is send to f and
after returning. x is increased, i.e f(x); x++;
Close. The value of x before the ++ is sent to f. The variable x is
also actually incremented before f is called, because there is a
sequence point at the call to f. This does not affect the value
sent to f.
3. undefined behavior, it is different for different compilers
No, the behaviour is not undefined.
I encountered the problem when I was porting code (not written by me)
from AIX to Linux. Visual age and gcc gave different results (2 and 1
respectively), so I had to manually change f(x++); to f(x); x++
in a lot of places because f(x++) was frequently used.

gcc gave you number 1 above? It doesn't for me. I get behaviour like
what I described above for three different compilers:

C:\prog\c>gcc henrik.c -o henrik_gcc

C:\prog\c>henrik_gcc
i = 0
called f(0) but now i = 1
i = 1

C:\prog\c>lc henrik.c -o henrik_lc.exe

C:\prog\c>henrik_lc
i = 0
called f(0) but now i = 1
i = 1

C:\prog\c>bcc32 -ehenrik_bcc.exe henrik.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
henrik.c:
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

C:\prog\c>henrik_bcc
i = 0
called f(0) but now i = 1
i = 1

C:\prog\c>type henrik.c
#include <stdio.h>

int i;

void f(int a)
{
printf("called f(%d) but now i = %d\n", a, i);
}

int main(void)
{
printf("i = %d\n", i);
f(i++);
printf("i = %d\n", i);
return 0;
}

--
Simon.

[Noah Roberts]

becte wrote:

What does the standard say about f(x++) ?
1. x is incremented and then the that value is
used in function f, i.e. x++; f(x);
2. the value of x (before ++) is send to f and
after returning. x is increased, i.e f(x); x++;
This one if f is a function. I could be wrong, but I don't think there
is any undefined behavior. 3. undefined behavior, it is different for different compilers
This one if f is a macro.
I encountered the problem when I was porting code (not written by me)
from AIX to Linux. Visual age and gcc gave different results (2 and 1
respectively), so I had to manually change f(x++); to f(x); x++
in a lot of places because f(x++) was frequently used.

[Simon Biber]

"Noah Roberts" <nr******@dontemailme.com> wrote:

becte wrote:

What does the standard say about f(x++) ? [snip] 3. undefined behavior, it is different for different compilers

This one if f is a macro.

Undefined behaviour if f is a macro?

#define f(i) printf("%d\n", i)

f(x++);

Where is the undefined behaviour?

--
Simon.

[Xenos]

>

Where is the undefined behaviour?

--
Simon.

I believe he was considering macros that make multiple accesses to a
parameter within a single sequence point.

DrX

[becte]

Thanks for the answers. Maybe I was oversimplifying a little bit.
The actual code looked like this

// gcc seems to be "wrong" here

listElement_s *listElement = &listElement[index];
// ...
memmove ((char *) listElement,
(char *) &list[index + 1],
sizeof (listElement_s) *
(noOfElements-- - index-- - 1));

The idea here is to "pack" a list of elements, i.e. remove an
element somewhere in the interior of the list
(listElement points to &list[index]) and
at the same time decrement noOfElements (and index).

In AIX (xlC) this works OK, but in Linux(gcc) the list is not "packed"
but noOfRoutePoints and routePointElementIndexWork are decreased.

To make it work in Linux I had to rewrite the code:

memmove ((char *) listElement,
(char *) &list[index + 1],
sizeof (listElement_s) *
(noOfElements - index - 1));
noOfElements--;
index--;

I assumed that the problem was that the decremented value of index
was used in memmove, so that index + 1 --> index. Then the
first and second arguments are equal and the list is not changed at all.

[Arthur J. O'Dwyer]

On Fri, 3 Oct 2003, becte wrote:

Thanks for the answers. Maybe I was oversimplifying a little bit.
The actual code looked like this

// gcc seems to be "wrong" here

listElement_s *listElement = &listElement[index];
// ...
memmove ((char *) listElement,
(char *) &list[index + 1],
sizeof (listElement_s) *
(noOfElements-- - index-- - 1));
This argument by itself is okay; but in combination with
the other arguments, which also try to use the value of
'index', it invokes undefined behavior. IOW, it's perfectly
well-defined and okay to write

foo(x++)

but it's entirely wrong and bad to write

foo(x, x++)

or

foo(x++, x)

or any combination of x++ and x without a sequence point
in between them. The ',' separator between function arguments
is *not* a sequence point, even though the comma operator (also
',', but in a different context) *is* a sequence point.

In AIX (xlC) this works OK, but in Linux(gcc) the list is not "packed"
but noOfRoutePoints and routePointElementIndexWork are decreased.
Yup. Undefined behavior will do that to you.
To make it work in Linux I had to rewrite the code:

memmove ((char *) listElement,
(char *) &list[index + 1],
sizeof (listElement_s) *
(noOfElements - index - 1));
noOfElements--;
index--;
That works.
I assumed that the problem was that the decremented value of index
was used in memmove, so that index + 1 --> index. Then the
first and second arguments are equal and the list is not changed at all.

It's undefined behavior; anything can happen.
Your fixed code is fine. Go with it. (Should've been
written that way from the start.)

-Arthur

[becte]

To clarify again; I checked your test programs and they work fine. E.g.

#include <stdio.h>

int f(int x)
{
printf ("Local x = %d\n",x);
return 0;
}

int main()
{
int i = 10;

f(i--);
return 0;
}

will return 10 in with gcc as well. So this simple case is OK.
The problem occurs only in the more complicated problem
with memmove.

[Thomas Lumley]

"Simon Biber" <ne**@ralminNOSPAM.cc> wrote in message news:<3f***********************@news.optusnet.com. au>...

"Noah Roberts" <nr******@dontemailme.com> wrote:

becte wrote:

What does the standard say about f(x++) ? [snip] 3. undefined behavior, it is different for different compilers

This one if f is a macro.

Undefined behaviour if f is a macro?

#define f(i) printf("%d\n", i)

f(x++);

Where is the undefined behaviour?

Presumably he meant that it *may* give undefined (or unspecified)
behaviour if f is a macro, eg
#define f(i) ((i)-(i))
#define f(i) (g(i)-g(i))
-thomas

[becte]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi***********************************@unix44 .andrew.cmu.edu>...

This argument by itself is okay; but in combination with
the other arguments, which also try to use the value of
'index', it invokes undefined behavior. IOW, it's perfectly
well-defined and okay to write

foo(x++)

but it's entirely wrong and bad to write

foo(x, x++)

or

foo(x++, x)

or any combination of x++ and x without a sequence point
in between them. The ',' separator between function arguments
is *not* a sequence point, even though the comma operator (also
',', but in a different context) *is* a sequence point.

This answers my question.
I wrote a small test program:

#include <stdio.h>

int i = 10;

int f(int a, int b)
{
printf ("a = %d, b = %d, Global i = %d\n", a, b, i);
return 0;
}

int main()
{
f(i, i--);
return 0;
}

In AIX (xlC) I get
a = 10, b = 10, Global i = 9
In Linux (gcc) I get
a = 9, b = 10, Global i = 9

[Peter Nilsson]

"becte" <he***************@hotmail.com> wrote in message
news:b4**************************@posting.google.c om...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi***********************************@unix44 .andrew.cmu.edu>...

This argument by itself is okay; but in combination with
the other arguments, which also try to use the value of
'index', it invokes undefined behavior. IOW, it's perfectly
well-defined and okay to write

foo(x++)

but it's entirely wrong and bad to write ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^
foo(x, x++) ^^^^^^^^^^^

f(i, i--) is no different.

or

foo(x++, x)

or any combination of x++ and x without a sequence point
in between them. The ',' separator between function arguments
is *not* a sequence point, even though the comma operator (also
',', but in a different context) *is* a sequence point.

This answers my question.
I wrote a small test program:

You can't test undefined behaviour.
#include <stdio.h>

int i = 10;

int f(int a, int b)
{
printf ("a = %d, b = %d, Global i = %d\n", a, b, i);
return 0;
}

int main()
{
f(i, i--);
The behaviour of the line is not defined by C. That doesn't merely mean that
the result is not specified, it means that *anything* can happen, including
a subsequent formatting of your harddisk.
return 0;
}

In AIX (xlC) I get
a = 10, b = 10, Global i = 9
In Linux (gcc) I get
a = 9, b = 10, Global i = 9

Your test program is flawed, so it can't demonstrate anything.

In any case, the mere observation that the same program generates different
results on two different implementations does not prove the program is in
error.

#include <stdio.h>

int f(void) { puts("f()"); return 42; }
int g(void) { puts("g()"); return 42; }

int main(void)
{
f() + g();
return 0;
}

This is a legitimate C program which can output one of two possible results.
But the language doesn't specify which one.

Expressions like (i + i++) and foo(i, i++) fall in a much worse category of
behaviour: undefined.

--
Peter