coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: nstrftime.c fails to build due to memset overflow
Date: Tue, 14 Mar 2023 16:50:57 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0

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

Attachment: coreutils-O0.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]