bug-gnulib
[Top][All Lists]
Advanced

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

Re: clang++ 11 compilation issues


From: Alexandre Duret-Lutz
Subject: Re: clang++ 11 compilation issues
Date: Thu, 14 Jan 2021 19:21:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Bruno Haible <bruno@clisp.org> writes:

> You are supposed to choose the warnings that are reasonable for your
> project. For some project of mine, I had to disable 20-40 warning options
> before I could get reasonable output.

That's exactly what I did :-) The set of warnings enabled in those
commands is the subset of warnings for which my project compiles
warning-free for that compiler on the different architectures I test.
Or at least it used to be warning free before I attempted to upgrade its
gnulib directory.

I have configure checks to detect which warning I can enable depending
on the compiler, and disable some warnings in version of GCC where they
are bogus.

I've done these extreme warnings on this project since 2003, but only on
my development builds, so I can detect and fix any new concerns brought
up by newer compiler versions.  Of course users builds are not done with
those options.

Obviously I target a much smaller and more modern set of systems than
gnulib, so I perfectly understand that you may not want to fix all
warnings.

>> > ../lib/gettext.h:234:22: error: zero as null pointer constant 
>> > [-Werror,-Wzero-as-null-pointer-constant]
>> >   if (msg_ctxt_id != NULL)
>> >                      ^~~~
>
> This will not be changed. 

I have another related suggestion.

My code is not internationalized.  gettext.h got pulled in because some
modules like argp are internationalized, but ENABLE_NLS will never be
defined in my project.

So this above warning is about code that will never be used, but for which
the compiler is still wasting resources for parsing and analyzing.

Would it be acceptable to replace all these pgettext functions by dummy
macros when NLS is disabled?
-- 
Alexandre Duret-Lutz



reply via email to

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