On 19/05/2023 17:39, Bruno Haible wrote:
Pádraig Brady wrote:
I'm going to keep this one.
...
I've lost many hours to analyzing false positives from this one ...
and I've never found a real issue identified by this warning.
But can you please remove the line
# FP wth -O0 in nstrftime.c w/gc
Pádraig Brady wrote:
> I'm going to keep this one.
> ...
> I've lost many hours to analyzing false positives from this one ...
> and I've never found a real issue identified by this warning.
But can you please remove the line
# FP wth -O0 in nstrftime.c w/gcc 12, and 13 at least
since we now hav
On 18/05/2023 22:27, Paul Eggert wrote:
Let's revert the "avoid incorrect -Wmaybe-uninitialized warnings" patch.
--enable-gcc-warnings is designed for the default gcc -O2, and we
shouldn't dumb down our source code for lesser platforms like "gcc -O0",
or clang, or whatever.
OK I'll revert.
I d
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.gn
Hey everyone,
Thanks for coming back to this.
As I said, I'm primarily not a fan of having different code paths depending on
build type; that makes debugging harder than necessary.
Just a remark, in theory, you can have the cake and eat it, but afterwards your
plate will be riddled with the cr
On 5/18/23 14:50, Bruno Haible wrote:
But when "gcc -Wall" reports 10 warnings to me, and I don't notice
that one of them is an actual bug because I mentally discard all of
them
If you're using -O0, then in my experience it's a mistake to also use
--enable-gcc-warnings, as the combination gene
Paul Eggert wrote:
> The goal here is software reliability not pacifying compilers
But when "gcc -Wall" reports 10 warnings to me, and I don't notice
that one of them is an actual bug because I mentally discard all of
them "oh these new warnings must all be false positives by gcc",
there is someth
--- 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
Let's revert the "avoid incorrect -Wmaybe-uninitialized warnings" patch.
--enable-gcc-warnings is designed for the default gcc -O2, and we
shouldn't dumb down our source code for lesser platforms like "gcc -O0",
or clang, or whatever.
For example, this patch:
- int dest_desc;
- int dest_e
On 14/03/2023 16: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 neces
Hi Bruno,
On 16.03.23 04:46, Bruno Haible wrote:
Apparently Paul and you have different ways of reading code, which
leads to different measures of "readability". You two could keep
contradicting each other eternally; that's not fruitful.
I don't intend to do that :) Paul seems to be the more exp
Hey Paul,
I think we're in agreement, even though I've been in the situation that the compiler
warning me about unitialized variable usage has saved me a lot of headache – and maybe
that's why I'm more sympathetic to making the compiler happy in such isolated circumstances.
We both would like t
> The goal should not be to pacify compilers' false alarms. The goal should be
> to have code that works correctly, is easy to understand, is efficient, etc.
In my personal code, when gcc complains about an uninitialized variable, even
if the code is correct, I usually either add an initializati
Hi Marcus,
Please try to understand Paul's arguments.
> Sorry to respectfully contradict you here: introducing a macro really
> doesn't do readability and immediate clarity of effect any better than
> a commented zero-initialization.
Apparently Paul and you have different ways of reading code,
On 3/15/23 16:03, Marcus Müller wrote:
introducing a macro really doesn't do readability
I don't want the macro either. Let's just leave the code alone.
I consider code paths that intentionally differ between debug and release builds
There's no need for that. Debug with the same options you
Hi Paul,
Sorry to respectfully contradict you here: introducing a macro really doesn't
do readability and immediate clarity of effect any better than a commented
zero-initialization.
I also disagree with your approach being less of a submission to the false (or
over-arching) compiler warnings
On 3/15/23 02:41, Marcus Müller wrote:
If my compiler doesn't optimize it away, well, then I have caused very
little overhead.
It's not really a question of overhead. Unecessary initializations make
code harder to understand. Polluting code with unnecessary
initializations together with comm
Hi Paul,
Uff, being a newb to this community, I feel really bad about giving my 2ct to roughly the
first thing I read on the mailing list, but:
Let's not do what GNU emacs does.
Having different code when linting and not linting makes bugs that only happen in
non-debug/lint builds impossible
On 3/14/23 09:50, Pádraig Brady wrote:
The attached also addresses -Wmaybe-initialized warnings in coreutils
that show up at lower optimization levels.
Let's not make that sort of change, please. It makes the code harder to
read and analyze, because I look at the code and wonder, "why is this
Hi Pádraig,
thanks for this patch!
Can confirm it really helps. However, I'd probably prefer it was merged as two separate
commits, as solving a wrong maybe-unitialized and a wrong no-stringop-overflow are two
different things (and also the approach at solving them is kind of different).
Tha
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 *tha
Pádraig Brady wrote:
>return cnt == digest_bin_bytes;
> }
>
> +# pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> static bool
> digest_check (char const *checkfile_name)
> {
Note that this pragma produces a warning with GCC versions < 4.7:
GCC 4.6.4:
foo.c:1:10: warning: unknown
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
23 matches
Mail list logo
