[Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081 --- Comment #6 from Peter Eisentraut peter_e at gmx dot net --- This particular case is in system headers, but there are other cases that are not, so this isn't going to help in general. I think this is a legitimate way to write a function-like macro that has a side-effect and a return value, and the warning is bogus.
[Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081 --- Comment #4 from Peter Eisentraut peter_e at gmx dot net --- Not really, because this code is in header files not under my control, and those header files should presumably work with a variety of C compilers and shouldn't need to rely on GCC extensions.
[Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081 Bug ID: 61081 Summary: excessive warnings: right-hand operand of comma expression has no effect Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: peter_e at gmx dot net OS X has the following system header definitions: #define sigaddset(set, signo) (*(set) |= __sigbits(signo), 0) #define sigdelset(set, signo) (*(set) = ~__sigbits(signo), 0) #define sigismember(set, signo) ((*(set) __sigbits(signo)) != 0) #define sigemptyset(set)(*(set) = 0, 0) #define sigfillset(set) (*(set) = ~(sigset_t)0, 0) gcc 4.9 with -Wall with complain about any use thereof with the newly introduced right-hand operand of comma expression has no effect I think the above programming patterns is common and legitimate in macros (search engines bring up similar cases) and without an elegant alternative. Warning about the right-hand expression having no effect is incorrect because it supplies the return value of the expression (unlike the left-hand side). I suggest that this warning be removed, or at least moved away from -Wall.
[Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081 --- Comment #2 from Peter Eisentraut peter_e at gmx dot net --- No, these functions need to have a usable return value, because someone could write if (!sigemptyset(...)) weirderror();
[Bug c/48778] New: gcc 4.6 -Waddress adds unhelpful new warning case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Summary: gcc 4.6 -Waddress adds unhelpful new warning case Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pete...@gmx.net Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6.1/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.6.1 20110329 (prerelease) (Debian 4.6.0-2) Consider this test file: #include stdlib.h typedef struct buf { size_t len; char *stuff; } buf; #define buflen(b) ((b) == NULL ? 0 : (b)-len) int func() { buf b; b.len = 5; b.stuff = malloc(5); if (buflen(b) 0) return 1; else return 0; } This compiles without warnings with -Wall on gcc =4.5. But gcc-4.6 -c -Waddress test.c test.c: In function ‘func’: test.c:18:12: warning: the comparison will always evaluate as ‘false’ for the address of ‘b’ will never be NULL [-Waddress] I don't think this is really helpful. Macros like in the above example are not uncommon, and there is no obvious way to write the code better.