| Summary: | C comma operator: wrong behavior | ||
|---|---|---|---|
| Product: | gcc | Reporter: | suan |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gcc-bugs, jsm28 |
| Priority: | P3 | Keywords: | wrong-code |
| Version: | 3.0.3 | ||
| Target Milestone: | --- | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
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 .... 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? |
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; }