This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/48778] New: gcc 4.6 -Waddress adds unhelpful new warning case
- From: "peter_e at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 26 Apr 2011 19:42:21 +0000
- Subject: [Bug c/48778] New: gcc 4.6 -Waddress adds unhelpful new warning case
- Auto-submitted: auto-generated
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: unassigned@gcc.gnu.org
ReportedBy: peter_e@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.