Re: stat-time.h vs. -Waggregate-return

[Simon Josefsson]

Eric Blake <address@hidden> 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