Some warnings depends on others: -Wformat-security won't work without
-Wformat. With -Wall we're confident enough that we have important
warnings enabled and in any case we're going to enable it anyway.
https://github.com/NetworkManager/NetworkManager/pull/175
With --enable-more-warnings, we already used -std=gnu99, see
commit ba2b2de3ad.
Compilation may behave differently depending on the selected
C standard that we choose. It seems wrong, with more-warnings,
to build against a C standard, while otherwise leaving it undefind.
Indeed, one might argue, that our build system should not use
such compiler specific options. At least, not without detecting
support for the compiler option during ./configure.
However:
- we already did this for --enable-more-warnings.
- we should not program against a theoretical compiler. In practice,
only gcc and clang works to build NetworkManager. Both these compilers
support this option, so there is no reason to not use it. If we ever
come into the situation to support another compiler, adjusting -std=gnu99
will be the smallest problem. Until that happens (and that's far from
imminent), don't pretend to be portable to non-existing compilers and
use the flag that in practice is available.
See-also: https://gcc.gnu.org/onlinedocs/gcc/Standards.html
Make it possible to add compiler options to a different variable than
CFLAGS. This is useful to conditionally disable a compiler warning for a
subpart of a tree.
We don't use them, so add a compiler warning about their use.
I think they are annoying, because sizeof(x) and typeof(x) might
evaluate at runtime. Especially the typeof() extension is useful
for macros, but behaves badly with variable-length arrays due to
running code at runtime.
But the worst is, G_STATIC_ASSERT() is implemented by declaring
an array of negative length. Usually, the checked condition should
be a compile time constant, but with VLAs the compiler would not evaluate
the static-assert at compile time and instead accept it silently. It's easy
to mess up static asserts to wrongly have a non-constant condition,
especially when the static-assert is used inside a macro.
Just say no.
src/NetworkManagerUtils.c:347:18: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
NMIPAddr a1 = { 0 }, a2 = { 0 };
^
{}
Should we initialize unions this way? I think it's all right -- the initializer
works well and { { { 0 } } } is probably not what we'd like to see.
(cherry picked from commit 43012156a3)
The warning seems questionable and overly strict.
For now, just disable it to allow building with gcc7.
src/systemd/src/basic/time-util.c: In function ‘format_timespan’:
src/systemd/src/basic/time-util.c:509:46: error: ‘%0*lu’ directive output between 1 and 2147483648 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-truncation=]
"%s"USEC_FMT".%0*"PRI_USEC"%s",
^~~~
src/systemd/src/basic/time-util.c:509:60: note: format string is defined here
"%s"USEC_FMT".%0*"PRI_USEC"%s",
src/systemd/src/basic/time-util.c:509:46: note: directive argument in the range [0, 18446744073709551614]
"%s"USEC_FMT".%0*"PRI_USEC"%s",
^~~~
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00001.html
We already use several GCC extenions, like typeof() and
__attribute__((cleanup)). They are too convinient to miss
and every supported compiler must support these.
Currently, gcc and clang does. Maybe other compilers would
support that too, but who knows, nobody seems to test that.
We also already use stdbool.h (C99) and the imported systemd
code is mostly gnu99 too (it's not clear to me, because I don't
find it precisely documented. Certainly it makes use of C99 features
too).
C99/gnu99 has some nice improvements that we no longer should miss
out. For example "flexible array members" or "variable declaration
in init-part of for loop".
It doesn't mean we have to use every obscure (badly supported?)
feature, it means we don't have to forgo features that are well
supported. C99 is 17 years old, I mean, really...
If somebody comes along and ports NM to non-gcc/clang, we can address
bugs about unsupported language features as they surface.
But let's not restrict us to some hypothetical compiler (or language
specification).
Also, NetworkManager is not ported on environment beside Linux.
We don't have to be so considerate about the required build environment.
Gcc is probably the most portable compiler out there. I doubt porting
NetworkManager to *BSD fails due to missing gnu99 features. And if that
causes issues, we should fix them after they happen in practice.
We break the aliasing rules in the code, and thus the flag should
always be enabled to prevent wrong optimizations, even without
--enable-more-warnings.
