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

[Pádraig Brady]

On 18/05/2023 22:43, Paul Eggert wrote:
> > --- 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.

I'm going to keep this one.

The bug above alludes to the plethora of issues with -Wstringop-overflow,
which is also my experience.
I've lost many hours to analyzing false positives from this one
(in a very large non coreutils code base),
and I've never found a real issue identified by this warning.

cheers,
Pádraig