Well, I suppose that one could argue that this is not a bug, but then it makes the feature much less useful. I think that this warning should do nothing when std=c++11 was not specified and therefore that nullptr is not supported. Currently G++ complains about 0 as a pointer even when it does not support nullptr! $ cat foo.cc int *p1 = 0; int *p2 = nullptr; $ g++-mp-4.7 -Wzero-as-null-pointer-constant /tmp/foo.cc /tmp/foo.cc:1:11: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] /tmp/foo.cc:2:11: error: 'nullptr' was not declared in this scope $ g++-mp-4.7 --version g++-mp-4.7 (GCC) 4.7.0 20120225 (experimental) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Oh well, changing this would be really trivial, but then people would have to globally switch-on -std=c++11 (which may not be otherwise appropriate) while working on removing (as much as possible) explicit zeros from C++98-era code. But really I don't have a personal strong opinion, and, as I mentioned already, a patch would be trivial. Jason, what shall we do?
And, hey, I don't really see what's the problem with not passing the -Wzero* at all if you don't want the warning. That can *always* be done, but if I once and for all prevent the -Wzero* from doing anything useful (or even being rejeted) when the default -std=c++98 is in effect, then, people who want to use it order to start removing explicit zeros (like, in conditionals and in many other context where it can easily be done without involving nullptr) don't have *any* help from the compiler. All in all, my current opinion is that we don't want to do this.
Note, even in the *specific* case at issue, maybe the user really wanted p1 statically initialized, or wants an early function call, or something like: typedef int* pt; int* p1 = pt(); (where pt will be std::nullptr_t in C++11 mode), who knows...
(In reply to comment #1) > Oh well, changing this would be really trivial, but then people would have to > globally switch-on -std=c++11 (which may not be otherwise appropriate) while > working on removing (as much as possible) explicit zeros from C++98-era code. I don't think this comment makes sense: with what would you want them to replace these 0, since nullptr is not available? I'm having precisely this problem in Bison. I want it to deliver code which compiles without warning on the user side (so I cannot play with Autoconf to check for nullptr support), so I use # ifndef YY_NULL # if 201103L <= __cplusplus # define YY_NULL nullptr # else # define YY_NULL 0 # endif # endif Unfortunately the user *will* have warnings if she passes the warning flag but not -std=c++11. This is even worse for C++03. $ g++-mp-4.7 -std=c++03 -Wzero-as-null-pointer-constant /tmp/foo.cc /tmp/foo.cc:1:11: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] /tmp/foo.cc:2:11: error: 'nullptr' was not declared in this scope Or, be consistent with the flags that rejected when misused (such as -Wmissing-prototypes that does not apply to C++) and reject that warning when not in std=c++11. The current status introduces non-killable warnings.
(In reply to comment #4) > I don't think this comment makes sense: with what would you want them > to replace these 0, since nullptr is not available? This does not read like I meant, sorry about this. It should be "I don't know how to make sense of that comment".
See my Comment #2 and #3: I'm still convinced that the warning can be useful in C++98 mode too. Unless Jason or another C++ front-end maintainer overrules me, I'm not going to do anything about this.
(In reply to comment #4) > Unfortunately the user *will* have warnings if she passes the > warning flag but not -std=c++11. So don't use that warning flag. It's not included in -Wall for good reason.
Closing.