g++ -c -Werror -Weverything exercise_2_17.cpp

[gdo...@gmail.com]

compiling a simple program, including <iostream>

using:
g++ -c -Werror -Weverything exercise_2_17.cpp

-Weverything is producing this:

g++ -c -Werror -Weverything exercise_2_17.cpp
error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
1 error generated.

if I don't use -Weverything source compiles fine, no errors or warning messages.

what does that mean?
using an intel based Mac, clang++ gives the same message.

Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

apparently g++ uses the clang++ compiler.

g++ -v
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

adding -Wsystem-headers gives so many warnings the it stops at its default limit.

[Öö Tiib]

On Tuesday, 27 December 2022 at 11:22:15 UTC+2, gdo...@gmail.com wrote:
> compiling a simple program, including <iostream>
>
> using:
> g++ -c -Werror -Weverything exercise_2_17.cpp
>
> -Weverything is producing this:
>
> g++ -c -Werror -Weverything exercise_2_17.cpp
> error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
> 1 error generated.
>
> if I don't use -Weverything source compiles fine, no errors or warning messages.
>
> what does that mean?
>

The -Weverything of clang produces all kinds of silly warnings some of what
you might want to disable. If you want to disable only that warning then
use -Wno-poison-system-directories

> using an intel based Mac, clang++ gives the same message.
>
> Apple clang version 14.0.0 (clang-1400.0.29.202)
> Target: x86_64-apple-darwin22.1.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> apparently g++ uses the clang++ compiler.
>
> g++ -v
> Apple clang version 14.0.0 (clang-1400.0.29.202)
> Target: x86_64-apple-darwin22.1.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> adding -Wsystem-headers gives so many warnings the it stops at its default limit.

Yes, there are no gcc installed on Apple by default. You need to install
it yourself if you want real gcc and of course there are artificial difficulties
made by Apple to that. But without challenges ... life is boring. ;-)

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> compiling a simple program, including <iostream>
>
> using:
> g++ -c -Werror -Weverything exercise_2_17.cpp
>
> -Weverything is producing this:
>
> g++ -c -Werror -Weverything exercise_2_17.cpp
> error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
> 1 error generated.
>
> if I don't use -Weverything source compiles fine, no errors or warning messages.

Don't enable all warnings. Some warnings are extremely specific and not even
intended for regular use, only for very special circumstances.

-Wall is a relatively safe bet. If you want a bit more, also add -Wextra.

[Paavo Helde]

There are other warnings in addition to -Wall -Wextra which I have found
to be useful for me, e.g.

-Wpointer-arith -Wcast-align -Wstrict-aliasing=1 -Werror=type-limits

And vice versa, -Wall -Wextra triggers some unneeded warnings which I am
switching off by -Wno-... options.

[Juha Nieminen]

Paavo Helde <ees...@osa.pri.ee> wrote:
>> Don't enable all warnings. Some warnings are extremely specific and not even
>> intended for regular use, only for very special circumstances.
>>
>> -Wall is a relatively safe bet. If you want a bit more, also add -Wextra.
>
> There are other warnings in addition to -Wall -Wextra which I have found
> to be useful for me, e.g.
>
> -Wpointer-arith -Wcast-align -Wstrict-aliasing=1 -Werror=type-limits

There was also the warning (which exact name I don't remember right now)
that will warn for uses of C-style casts. Depending on how much of a
C++ purist one is, it might also be worth considering.

> And vice versa, -Wall -Wextra triggers some unneeded warnings which I am
> switching off by -Wno-... options.

Can you give some examples?

[Paavo Helde]

Sure, these are probably specific to our codebase:

-Wno-missing-field-initializers -Wno-unused-parameter
-Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses

The first one is there probably because we have many classes whose
members are often not initialized by the constructions, but later, by
the framework.

[Juha Nieminen]

Paavo Helde <ees...@osa.pri.ee> wrote:
> Sure, these are probably specific to our codebase:
>
> -Wno-missing-field-initializers -Wno-unused-parameter
> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>
> The first one is there probably because we have many classes whose
> members are often not initialized by the constructions, but later, by
> the framework.

I think that using [[maybe_unused]] is better than disabling the warning
because it more explicitly indicates that it being unused is not a mistake
and the programmer was aware of it.

One warning, or was it actually an error, that does annoy me quite a bit
is the "narrowing conversion" thingie. I think it was introduced in C++11
or newer, and was never a problem before. To this day I'm not sure why
that warning/error is necessary.

(Maybe it has something to do with uniform initialization, which turned
out to be quite a mess?)

[David Brown]

On 31/12/2022 16:05, Juha Nieminen wrote:
> Paavo Helde <ees...@osa.pri.ee> wrote:
>> Sure, these are probably specific to our codebase:
>>
>> -Wno-missing-field-initializers -Wno-unused-parameter
>> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>>
>> The first one is there probably because we have many classes whose
>> members are often not initialized by the constructions, but later, by
>> the framework.
>
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.
>

It also has the advantage of allowing people to compile with other flags
(such as -Wextra without the -Wno- flag) without triggering the warning.

> One warning, or was it actually an error, that does annoy me quite a bit
> is the "narrowing conversion" thingie. I think it was introduced in C++11
> or newer, and was never a problem before. To this day I'm not sure why
> that warning/error is necessary.
>
> (Maybe it has something to do with uniform initialization, which turned
> out to be quite a mess?)

I think warnings (or errors) about narrowing conversions are a good
idea. If I accidentally try to use a double as an integer, I'd rather
be told.

I find the "uniform initialisation" syntax ugly for scaler variables,
but the fact that narrowing conversions are not allowed is an advantage
here IMHO.

[Paavo Helde]

31.12.2022 17:05 Juha Nieminen kirjutas:
> Paavo Helde <ees...@osa.pri.ee> wrote:
>> Sure, these are probably specific to our codebase:
>>
>> -Wno-missing-field-initializers -Wno-unused-parameter
>> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>>
>> The first one is there probably because we have many classes whose
>> members are often not initialized by the constructions, but later, by
>> the framework.
>
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.

You are right in that the unused parameter warnings should be dealt
case-by-case instead of a global compiler option. I guess there was no
time or willingness to do that when the compiler suddenly started to
spit out hundreds of such warnings, and after adding the global option
there has been no motivation to do that.

Still, I'm not convinced [[maybe_unused]] is the best solution always.
As far as I can see, this is meant more for conditional compilation,
where a thing might be indeed sometimes used and sometimes not,
depending on preprocessor macro definitions.

In my code, I get this warning mainly for virtual function overrides
where some parameter is e.g. only used by 1 override of 10. And in those
9 other overrides the parameter is not maybe unused, but definitely
unused. Alas, by some reason there is no [[unused]] attribute.

In this scenario, I believe it might be better (i.e. more readable) to
just delete or comment out the parameter name, it will have the same
effect.

[David Brown]

That can often be the best choice - though of course "best" will depend
on many things.

Another option is a cast to void - I believe most compilers treat that
as considering the parameter "used" without generating any code. You
may feel a comment is warranted to explain what you are doing.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
>> One warning, or was it actually an error, that does annoy me quite a bit
>> is the "narrowing conversion" thingie. I think it was introduced in C++11
>> or newer, and was never a problem before. To this day I'm not sure why
>> that warning/error is necessary.
>>
>> (Maybe it has something to do with uniform initialization, which turned
>> out to be quite a mess?)
>
> I think warnings (or errors) about narrowing conversions are a good
> idea. If I accidentally try to use a double as an integer, I'd rather
> be told.

The problem is that the "narrowing" warning/error is only issued when
eg. using a double within an initializer list that expects a float,
it doesn't happen in *any* other situation where a double is being
implicitly converted into a float.

I cannot comprehend the reason to make that one particular situation
special.

[David Brown]

It is better than nothing.

But I agree with you that narrowing conversions can definitely be wrong,
or at least risky, in other circumstances too. /Increasing/ the type
size silently can also be an issue (imagine using a microcontroller with
hardware single-precision floating point, but doubles in software -
these are very common).

C++ inherited a range of automatic conversions and promotions from C.
They are often convenient, but occasionally problematic. They can't be
removed from the language - backwards compatibility is too strong for
that. It would usually not make sense to have compiler warning options
either, as the false positives would likely swamp the useful warnings.

As I see it, there are three options. Switch to a stricter language,
such as Ada. Make your own types, such as "Float" and "Double", without
automatic conversions. Or campaign for a new feature in C++ where a
declaration like "void foo(explicit float f)" would require a float
argument without conversion.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
>> I cannot comprehend the reason to make that one particular situation
>> special.
>
> It is better than nothing.

Now that I think about it, I actually don't know if the "narrowing
conversion" warning given by gcc (and I think also clang) when such
a conversion happens in initializer lists in particular is just
because the developers of the compiler decided so, or whether the
newer C++ standards mandate something along those lines.

However, looking it up, it seems that indeed the C++11 standard
forbids list-initialization with implicit narrowing conversions.
(It also seems to disallow it for aggregate initialization.)

It's a bit annoying to have this inconsistency in the language.
(Overall, as great as "uniform initialization" sounds on paper,
in practice it causes a lot of headaches. At a very minimum they
should have used a different syntax for initializer lists.)

[David Brown]

On 03/01/2023 10:13, Juha Nieminen wrote:
> David Brown <david...@hesbynett.no> wrote:
>>> I cannot comprehend the reason to make that one particular situation
>>> special.
>>
>> It is better than nothing.
>
> Now that I think about it, I actually don't know if the "narrowing
> conversion" warning given by gcc (and I think also clang) when such
> a conversion happens in initializer lists in particular is just
> because the developers of the compiler decided so, or whether the
> newer C++ standards mandate something along those lines.

The standards mandate it (as you note below).

>
> However, looking it up, it seems that indeed the C++11 standard
> forbids list-initialization with implicit narrowing conversions.
> (It also seems to disallow it for aggregate initialization.)
>
> It's a bit annoying to have this inconsistency in the language.
> (Overall, as great as "uniform initialization" sounds on paper,
> in practice it causes a lot of headaches. At a very minimum they
> should have used a different syntax for initializer lists.)

I think a bit of inconsistency and ugly syntax is almost inevitable here
- backwards compatibility makes it practically impossible to change
existing behaviour. I don't know how the language could have done
anything better here.