On 11/30/2011 03:20 AM, Simon Josefsson wrote: > Eric Blake <ebl...@redhat.com> writes: > >> On 11/29/2011 02:46 PM, Eric Blake wrote: >>>> Unless there are objections (portability?) >>> >>> Aargh. I just reread C99. >>> >>> F (and f) for float, and L (or l) for long double are required, but D >>> (or d) for double is a GNU extension. >>> >>> Since we can't silence the warning without adding an explicit 'D', but >>> 'D' is not standardized, I have changed my mind. Let's nuke the warning. >> >> So for starters, I'm pushing this: > > Please revert or change this -- like other warnings, this warning is > useful in some projects and not useful in others, and the idea with > manywarnings.m4 is that all warnings should be enabled and each project > has to disable the warnings they don't like incrementally. See > doc/manywarnings.texi for background.
We already concluded that the warning is bogus as a reasonable warning - there is no way to write portable code that both complies with C99 and silences the warning without either ditching 'double' (using only 'float' and 'long double' constants) or using non-standard extensions (gcc's '1.0D' for double). But I can see your counterargument of having a complete list of all possible gcc warnings, followed by a second list that filters out warnings that make no sense in a gnulib project, as well as lists of warnings that make no sense in a C-only, a C++-only, and a dual C/C++ program. For example, -Wc++-compat makes no sense for a C-only program, but makes perfect sense for a dual C/C++ program. Libtool is an example of a dual program, that strives to use the subset of C and C++ so that it can be compiled by either language for use in both C and C++ programs. If we have various filter lists, for all warnings minus those not suited for this typical usage pattern, as well as a way to easily select which filters to apply, that would indeed be nicer. -Wunsuffixed-float-constants should then appear on the list of all warnings, but also on pretty much every filter list as being worthless for portable code. We could also have a filter list for warnings that will not work with gnulib code directly, but which projects may still wish to use on their own code (see how coreutils has split warning levels, for example). > I'm fine with creating another function gl_MANYWARN_ALL_REASONEBLE_GCC > or similar if you prefer that, but let's keep the base function clean > from subjective filtering of warning flags. It should just generate a > list of all warning flags that can possibly be enabled in gcc. Maybe more like gl_MANYWARN_ALL_GCC_EXCEPT(VARIABLE, [EXCLUSION]), where it would be called like: gl_MANYWARN_ALL_GCC_EXCEPT([WARN_CFLAGS], [gl_MANYWARN_NO_C++_WARNINGS]) gl_MANYWARN_ALL_GCC_EXCEPT([GNULIB_WARN_CFLAGS], [gl_MANYWARN_NO_C++_WARNINGS], [gl_MANYWARN_NO_GNULIB_WARNINGS]) -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
