Re: nstrftime.c fails to build due to memset overflow

[Paul Eggert]

> --- a/configure.ac
> +++ b/configure.ac
> @@ -261,6 +261,11 @@ if test $gl_gcc_warnings != no; then
>    # FP in careadlinkat.c w/gcc 10.0.1 20200205
>    gl_WARN_ADD([-Wno-return-local-addr])
>  
> +  # FIXME: remove this line when gcc improves
> +  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
> +  # FP wth -O0 in nstrftime.c w/gcc 12, and 13 at least
> +  gl_WARN_ADD([-Wno-stringop-overflow])

This patch doesn't look right either. First, 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443> is a meta-bug 
report, and so is too vague for anybody to see what problem the FIXME is 
referring to. The FIXME should refer to a specific GCC bug report, and 
if no such bug report exists one should be created.

Second, if the bug occurs with -O0 but not with -O2, then gl_WARN_ADD 
should be invoked only if -O0 is specified. -Wstringop-overflow is a 
useful option and should not be suppressed for ordinary (-O2) builds 
simply because there's a problem in -O0 builds.

More generally, I don't think we should spend much time worrying about 
configuring with --enable-gcc-warnings and compiling with -O0. With 
today's GCC it's better to say, "don't do that". That is, either 
configure with a high quality of static checking, with 
--enable-gcc-warnings; or configure with easy-to-debug options like 
CFLAGS="-O0". The current GCC can't do both well, and there's little 
sense making application code less reliable in order to try to make GCC 
do a little bit better for this poorly-supported combination.