Bug 6409 - C comma operator: wrong behavior
Summary: C comma operator: wrong behavior
Status: RESOLVED DUPLICATE of bug 11751
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.0.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: wrong-code
Depends on:
Reported: 2002-04-22 10:06 UTC by suan
Modified: 2005-04-21 04:58 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description suan 2002-04-22 10:06:01 UTC
	Best illustrated by example:

	1.  int val;
	2.  (val=11)
	3.  + (val=22,
	4.     printf("VAL = %d\n", val)
	5.    );

	Line 4 outputs "11" rather than the expected "22".

	C specs define a sequence point at the comma operator,
	so by the "at-most-one-write" semantics of expressions,
	val should be 22 at line 4.
	(Its value at line 6, of course, is undefined, due to
	 the arbitrary order-of-evaluation for the + operator.)


System: Linux cygnet.cs.wisc.edu 2.4.17-csl1smp #1 SMP Mon Jan 7 16:44:21 CST 2002 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /s/gcc-3.0.3/src/gcc-3.0.3/configure --prefix=/s/gcc-3.0.3/i386_rh72 --enable-shared --enable-threads

Note: bug also manifested in <sparc-sun-solaris2.8> version, and version 3.0.4 (linux) as well.

	Just compile (gcc, no special flags needed) and run the following:

	int main()
	  int val;

	  + (val=22, printf("VAL = %d\n", val));

	  return 0;
Comment 1 suan 2002-04-22 10:06:01 UTC
	Don't know.
Comment 2 Joseph S. Myers 2002-04-22 10:16:11 UTC
State-Changed-From-To: open->closed
State-Changed-Why: Sequence points define a partial ordering, not a total
    ordering.  There is no ordering in the example between
    (val=11) and any part of the other argument of +.  Both
    arguments of the comma operator conflict with (val=11),
    causing undefined behavior if this code is ever executed
    (so the compiler can make deductions on the basis that
    it never will be executed).
Comment 3 Andrew Pinski 2005-04-20 02:59:28 UTC
Reopening to ....
Comment 4 Andrew Pinski 2005-04-20 02:59:39 UTC
Mark as a dup of bug 11751.

*** This bug has been marked as a duplicate of 11751 ***
Comment 5 suan 2005-04-21 02:34:28 UTC
Hmm... now that I've been reminded of this bug, I might as well try to revive it.
I think my question has more to do with the granularity of well-defined-ness. 
Consider the expression A + (B,C), which contains a subexpression (B,C) which is
itself an expression.  If the expression (B,C) does not contain conflicts,
should not its behavior be well-defined?  Should not the A-B/A-C conflict in the
outer expression mean only that the outer expression's behavior be undefined,
and not affect the well-defined-ness of the inner expression?
Comment 6 Andrew Pinski 2005-04-21 04:58:40 UTC
(a,b) where a and b change is the only thing where it is defined.
c + (a,b) where c and b change the same variable is undefined.
Likewise for c and a.

*** This bug has been marked as a duplicate of 11751 ***