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

[Marcus Müller]

Hi Pádraig,

ah, this literally came in as I sent my reply to Bruno (and of course mistyped his name; 
sorry!); indeed, that makes "sense" (as far as sense and compiler bugs go well together), 
less optimization means fewer stages of constant folding etc; however, it's surprising 
that GCC is *that* buggy here.

Cheers,
Marcus

On 14.03.23 17:50, Pádraig Brady wrote:
> On 14/03/2023 13:55, Marcus Müller wrote:
> > Dear Gnulib community,
> >
> > On Linux, x86_64, Fedora 37, ran, on today's coreutils' HEAD (e68b15), which 
> > submodule-includes gnulib f17d3977:
> >
> > CFLAGS=-Wno-deprecated-declarations ./configure
> >
> > (as that CFLAGS is necessary, otherwise sha will fail to build due to using deprecated 
> > functionality; no big issue).
> > However, building coreutils fails in gnulib and that does seem to be a 
> > significant bug:
> >
> > make -j8 fails with
> >
> > lib/nstrftime.c: In function '__strftime_internal':
> > lib/nstrftime.c:147:31: error: 'memset' specified size 18446744073709551615 exceeds 
> > maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
>
> This is triggered by -O2 being implicitly removed when you specified the CFLAGS 
> explicitly.
> I.e. there are gcc false positives at lower optimization levels.
>
> Also you're building from git, and so will have more strict
> developer appropriate warning settings by default
> (which can be controlled with the --enable-gcc-warnings=no configure option).
>
> In my experience of this particular "stringop-overflow" warning,
> I've had to work around it so many times in a large build system in work
> that I disabled it by default in the central build config.
> It probably makes sense to disable this in the coreutils settings at least,
> which is done in the attached.
> The attached also addresses -Wmaybe-initialized warnings in coreutils
> that show up at lower optimization levels.
>
> cheers,
> Pádraig