Compiler bug - Postincrement & Preincrement operators

[Jinesh]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

---------------------------Code------------------------------
#include <stdio.h>

void main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]);
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1
--------------------------------------------------------------
Shouldn't the output be all 1's. Why is this happening? Anyone have a
clue?
Operating System: IRIX 6.5.21 (if that helps!!)

Thanks a ton in advance,
-Jin

 

[Andreas Kahari]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:- [cut]
printf("The element in slot %d is %d\n", (i++), array[(--i)]);

You're not guaranteed a specific order of evaluation for the
arguments of functions. Java, for example, says that the
arguments should be evaluated left-to-right, but C doesn't say
anything about it at all.

 

[Irrwahn Grausewitz]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

Well, I'm far from being a Guru, but let' have a look

---------------------------Code------------------------------
#include <stdio.h>

void main(void) int main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]); return 0;
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1

Yes: you are not guaranteed in which particular order the arguments
passed to a function will get evaluated. So, to get the result you
expected, you would have to write:

printf("The element in slot %d ", i++ );
printf("is %d\n", array[--i] );

A decent compiler will give you a diagnostic for your original code,
if the warning level is adjusted properly.

Operating System: IRIX 6.5.21 (if that helps!!)

Thanks a ton in advance,
-Jin

Irrwahn

 

[Martin Dickopp]

printf("The element in slot %d is %d\n", (i++), array[(--i)]);

This causes undefined behavior, because you modify `i' more than once
without intervening sequence point. It is therefore wrong to have /any/
expectation about the program behavior.

Martin

 

[Jack Klein]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

Well, I'm far from being a Guru, but let' have a look

---------------------------Code------------------------------
#include <stdio.h>

void main(void) int main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]); return 0;
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1

Yes: you are not guaranteed in which particular order the arguments
passed to a function will get evaluated. So, to get the result you
expected, you would have to write:

It's even worse than that, since there is no sequence point between
the evaluation of function arguments, so it's undefined behavior.

printf("The element in slot %d ", i++ );
printf("is %d\n", array[--i] );

A decent compiler will give you a diagnostic for your original code,
if the warning level is adjusted properly.

Compilers are not required to warn about undefined behavior. In fact,
I don't think I have seen one that would warn about this, although a
good lint certainly would.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Irrwahn Grausewitz]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

Well, I'm far from being a Guru, but let' have a look

---------------------------Code------------------------------
#include <stdio.h>

void main(void) int main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]); return 0;
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1

Yes: you are not guaranteed in which particular order the arguments
passed to a function will get evaluated. So, to get the result you
expected, you would have to write:

It's even worse than that, since there is no sequence point between
the evaluation of function arguments, so it's undefined behavior.

My fault, you are right.

printf("The element in slot %d ", i++ );
printf("is %d\n", array[--i] );

A decent compiler will give you a diagnostic for your original code,
if the warning level is adjusted properly.

Compilers are not required to warn about undefined behavior. In fact,
I don't think I have seen one that would warn about this, although a
good lint certainly would.

Well, I have, at least one (gcc 3.2):

gcc.exe "D:\Temp\UB.c" -o "D:\Temp\UB.exe" -W -Wall -fmessage-length=0
-g3 -I"C:\Programme\DevCpp5b8\include" -L"C:\Programme\DevCpp5b8\lib"
D:/Temp/UB.c: In function `main':
D:/Temp/UB.c:9: warning: operation on `i' may be undefined

Which clearly indicates, that, if I had read the warning carefully,
I would have noticed it's actually UB. Doh!

Irrwahn

 

[Mantorok Redgormor]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

Well, I'm far from being a Guru, but let' have a look

---------------------------Code------------------------------
#include <stdio.h>

void main(void) int main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]); return 0;
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1

Yes: you are not guaranteed in which particular order the arguments
passed to a function will get evaluated. So, to get the result you
expected, you would have to write:

It's even worse than that, since there is no sequence point between
the evaluation of function arguments, so it's undefined behavior.

I thought the comma operator was a sequence point?

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.
[2] - Second sequence point.

printf("The element in slot %d ", i++ );
printf("is %d\n", array[--i] );

A decent compiler will give you a diagnostic for your original code,
if the warning level is adjusted properly.

Compilers are not required to warn about undefined behavior. In fact,
I don't think I have seen one that would warn about this, although a
good lint certainly would.

 

[Irrwahn Grausewitz]

I thought the comma operator was a sequence point?

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.
[2] - Second sequence point.

There is no comma operator, and therefore no sequence point at the
indicated positions. We are looking at the miracle of a comma-separated
argument-list. ;-)

<SNIP>

--
do not write: void main(...)
do not use gets()
do not cast the return value of malloc()
do not fflush( stdin )
read the c.l.c-faq: http://www.eskimo.com/~scs/C-faq/top.html

 

[Chris Dollin]

I thought the comma operator was a sequence point?

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.
[2] - Second sequence point.

Those are not comma operators; they're commas separating arguments.

[Since the meaning of the comma operator "A, B" is "evaluate A,
discard the result, evaluate B, deliver B's result as your own",
pretty clearly comma operators in C would be slightly useless for
making argument lists ...]

 

[Kevin Easton]

On Fri, 12 Sep 2003 01:30:45 +0200, Irrwahn Grausewitz


It's even worse than that, since there is no sequence point between
the evaluation of function arguments, so it's undefined behavior.

I thought the comma operator was a sequence point?

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.
[2] - Second sequence point.

The comma operator does introduce a sequence point, but those commas are
not comma operators - they are comma punctuators that seperate
function call arguments.

- Kevin.

 

[Christian Bau]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

It's the second.

Modifying an object twice without intervening sequence point is
undefined behavior. Using i++ and --i in the same expression means
_anything_ can happen.

---------------------------Code------------------------------
#include <stdio.h>

void main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]);
}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1
---------------------Expected Output--------------------------
The element in slot 1 is 1
The element in slot 1 is 1
--------------------------------------------------------------
Shouldn't the output be all 1's. Why is this happening? Anyone have a
clue?
Operating System: IRIX 6.5.21 (if that helps!!)

Thanks a ton in advance,
-Jin

 

[Christian Bau]

I thought the comma operator was a sequence point?

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.
[2] - Second sequence point.

There is no comma operator. There is a comma separating arguments. What
you are thinking about is

foo ((++i, ++i));

which is a function call with _one_ argument and well defined behavior.

 

[Jinesh]

Hmm...these responses make me think twice about all of my development
work in the past. There should be serious concerns about the science
originating from my office.

-Jin

 

[The Real OS/2 Guy]

Dear Guru's:

Have a simple C questions. Is this a bug or am I doing something
reallllly stupid? Here's the code snippet:-

---------------------------Code------------------------------
#include <stdio.h>

void main(void)
{
int i=1;
int array[] = {0, 1, 2, 3, 4};

printf("The element in slot %d is %d\n", i, array);
printf("The element in slot %d is %d\n", (i++), array[(--i)]);

undefined behaviour. You can't not modify the same variable twice
between 2 sequence points without püroducing undefined behavior. The
comma in a parameter list is NOT a sequence point.

The paranthenses around i++ and --i are completely useless.

}
----------------------Actual Output---------------------------
The element in slot 1 is 1
The element in slot 0 is 1

You can't expect any usefull output. Undefined behavior can make nasal
demons flying out of your nouse, crashing the system, initiate the 3.
world war or even give some unwanted results.

 

[The Real OS/2 Guy]

I thought the comma operator was a sequence point?

Yes, the comma operator is a sequence point, but the comma in a
paramer list is NOT the comma operator, it's just a parameter
separator.

foo("hello %d %d\n",[1] ++i ,[2] ++i);

[1] - First sequence point.

no, seperate parameter one from two, nothing else.

[2] - Second sequence point.

on, only another separator.

x = i++, --i;
here is the comma the comma operator. the result is what --i delivers.