Akim Demaille wrote: > I have submitted this patch several times in this thread (starting at > http://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00049.html), > and for some reason it remains unnoticed, and uncommented. Please let > me know what is wrong in my approach. > > I would like to wrap a Bison 2.5.1 soon, and I expect to use this > patch to decide whether I enable -Wzero-as-null-pointer-constant (as > G++ can happily reject 0 as a pointer without supporting nullptr, not > considered as a bug by G++ people).
Hi Akim, I was burned by that, too, while trying to build bison using gcc-4.8.x. > The attached patch enhances warnings.m4 in several ways: > > - gl_COMPILER_OPTION_IF allows to define more fine grain tests on the > behavior of the compiler. Forcing the result to be an assignment to > a variable (which is AC_SUBST'ed) does not seem to offer the > orthogonal design one would expect. This would be useful elsewhere, > for instance in manywarnings, as I have already reported > (http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00198.html) > > - separating the diagnostic part from the action part provides a > cleaner way to implement test cases. > > - separating the diagnostic part from the action part helps extending > both in a cleaner way: > > - it allowed me to cleanly integrate the missing AC_SUBST for > WARN_CFLAGS instead of leaving this to modules/warnings > > - it will make it easier to check for the answers of the compiler on > stderr (as currently, we merely check whether the compiler rejects > the candidate option with an error status; this results in uselessly > long compilation command lines, and spurious warnings in some > situations). > > - the added parameter to gl_WARN_ADD allows to fine tune whether a > given warning is wanted or not (e.g., 0 vs. nullptr as above). I like the patch. If no one objects, I'll push it later today.
