Eric Blake <ebl...@redhat.com> writes: > On 08/02/2012 04:49 PM, Paul Eggert wrote: >> On 08/02/2012 03:40 PM, Eric Blake wrote: >>> /* Store *ST's access time into *TS. */ >>> static inline void >>> get_stat_atime (struct stat const *st, struct timespec *ts) >> >> I'd rather not go that route, as the functional style is easier >> to read -- in particular, it tends to avoid aliasing issues. >> >> In the GNU apps I'm familiar with (Emacs, coreutils, ...) >> we simply disable -Waggregate-return. It a completely >> anachronistic warning, since its motivation was to >> support backwards compatibility with C compilers that >> did not allow returning structures. Those compilers >> are long dead and are no longer of practical concern. > > Fair enough; that argues that 'manywarnings' should be customized to > easily ditch this and other anachronistic warnings (for example, > -Wtraditional, -Wlong-long) in one line, rather than making every single > client repeat the same list of customizations.
I agree the current situation could be improved, and we have touched on this before. I would prefer to solve this with a two-step approach: 1) The goal of the manywarnings module should be to discover ALL warning flags that the compiler supports, whether the warning message is useful or not [as long as it doesn't break builds]. Having the complete list of warnings a compiler support available can be useful for experimenting with various coding styles. 2) There could be a 'reasonablewarnings' module that depended on manywarnings, which would do further filtering of the warning list to limit it to warning flags relevant to GNU-style project. This module could remove flags like -Wtraditional, -Wsystem-headers and others which we consider useless for the majority of projects. What do you think? (maybe the module names should be improved though) /Simon
