GCC Bugzilla – Bug 6409
C comma operator: wrong behavior
Last modified: 2005-04-21 04:58:40 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.) Release: 3.0.3 Environment: 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. How-To-Repeat: Just compile (gcc, no special flags needed) and run the following: int main() { int val; (val=11) + (val=22, printf("VAL = %d\n", val)); return 0; }
Fix: Don't know.
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).
Reopening to ....
Mark as a dup of bug 11751. *** This bug has been marked as a duplicate of 11751 ***
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?
(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 ***