glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.
However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.
Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.
Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.
It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?
Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.
See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
We redefine G_VARIANT_TYPE() because we don't want to pay a run time
check for what should be a simple cast.
But this is strictly tied to glib, and it must only be done after glib.h
was included. Move it to the right place.
autotools projects commonly should include "config.h" as first header.
Also, commonly we need more headers, like glib.h or our nm_auto macros.
Hence, almost all our sources should as first include "nm-default.h".
However, as we build different parts, "nm-default.h" gets controlled
by the NETWORKMANAGER_COMPILATION define which autotools/meson needs
to specify in the build options.
That is confusing.
One advantage of that was, that theoretically the same sources can
be built twice, with different behavior. However, we should avoid doing
that altogether and build static libraries (once) that we link multiple
times.
Another advantage was that if NETWORKMANAGER_COMPILATION is for example
set to build a DAEMON source, there is a check that we don't include
private headers from libnm-core. However, that should be better solved
by not having public, internal and private headers in the same
directory.
Instead, introduce different "nm-default-*.h" headers that don't require
special defines and behave in a consistent way. This way, we require
fewer CFLAGS and it's immediately clear by looking at the source alone
which headers are included. Also, you will be easier see when a wrong
nm-default-*.h header gets included.
Introduce the first replacement. The others will follow.
The change broke unit tests on 32 bit systems.
Change the code again to make it more similar to what it was
before. Now only on 64 bit systems there is any difference compared
to before. That makes it easier about reasoning for how the unit test
should be (in most cases, it is unchanged).
Fixes: 040c86f15c ('shared: avoid compiler warning for nm_utils_get_next_realloc_size() returning huge sizes')
On s390x (gcc-8.3.1-5.1.el8.s390x) the compiler warns that we don't
pass size larger than 2^63-1 to malloc. With LTO enabled, it is also
quite adamant in detecting that with nm_utils_get_next_realloc_size().
Optimally, we would disable this useless warning with "-Wno-alloc-size-larger-than",
but that seems not to work. So add a workaround in code :(
It's hard to actually workaround the warning while handling all kinds of
sizes. The only simple solution is to no handle such huge cases and only
assert.
In function 'nm_secret_mem_realloc',
inlined from '_nm_str_buf_ensure_size' at shared/nm-glib-aux/nm-shared-utils.c:5316:31:
shared/nm-glib-aux/nm-secret-utils.h:180:17: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
m_new = g_malloc(new_len);
^
shared/nm-glib-aux/nm-secret-utils.h: In function '_nm_str_buf_ensure_size':
/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function 'g_malloc' declared here
gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1);
^
lto1: all warnings being treated as errors
"shared/nm-std-aux/unaligned.h" is taken from systemd and frequently
re-imported via the "systemd" branch.
It is not our code, and should not be formatted with our clang-format.
Kernel uses such typedefs (__le32) and systemd too (le32_t).
As we don't want to rely on systemd headers in our code
base, let's also define them.
They have of course very little effect beside making it clearer to
the reviewer that a certain variable is not supposed to be in native
endianness.
While we often use and prefer the glib typedefs (like guint32), there
are places where we want to use the fixed width integer types from C99.
In particular, next we will introduce typedefs like nm_le64_t for
integers in different endianness.
Also, here we are about "nm-std-aux", so the glib typedefs are not
available.
I feel a header like <stdint.h> is such a basic C requirement, that
is should just be available to us everywhere.
I would need these macros earlier in "nm-glib-aux/nm-shared-utils.h",
so it would be sufficient to just move them.
However, when I already move them, move them to "nm-std-aux/nm-std-aux.h"
because they don't need a glib dependency.
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
They are like NM_STR_HAS_SUFFIX()/NM_STR_HAS_SUFFIX_ASCII_CASE(), but require that
the checked string is not identical to the suffix. They require some non-empty word
preceding the suffix.
This makes the macro more function like. Also, taking a pointer
makes it a bit clearer that this possibly changes the value.
Of course, it's not a big difference to before, but this
form seems slightly preferable to me.
This is of course trivial. However, we use this macro at several places
as and index into an array of length 2, to lookup either the IPv4 or
IPv6 element. As such, this MUST return 0 or 1. This promise is what the
macro should convey.
There is the team of nm_auto*, nm_clear_pointer() and nm_steal_pointer().
These goes nicely together so that an autovariable owns a resource,
to free it (clear) and to transfer ownership (steal).
We have these also in glib, but we certainly also need it if we don't
have glib because that very much goes together with nm_auto*. Add it.
For a long time already we build with gnu11/C11. We thus rely on having
<stdbool.h> around, which is C99. Use it.
Also fix "nm-std-aux.h" to not use TRUE/FALSE glib defines.
We redefine _G_BOOLEAN_EXPR(), so let it use NM_BOOLEAN_EXPR().
Also, we use G_LIKELY() (and thus NM_BOOLEAN_EXPR()) inside nm_assert(),
and we use nm_assert() in some macros. To be able to nest nm_assert()
calls, we need to create unique variable names for NM_BOOLEAN_EXPR().
Having assertion macros that are disabled by default, is not
only useful for our glib code, but should also be available
for nm-std-aux. Move the macros.
"nm-dbus-compat.h" was GPL licensed. That is a problem, because we use it from
libnm (which is LGPL).
The history of this file in NetworkManager source tree:
$ git shortlog -n -s e055bdbbc3 -- shared/nm-std-aux/nm-dbus-compat.h include/nm-dbus-compat.h shared/nm-dbus-compat.h
5 Thomas Haller
1 Dan Winship
1 Lubomir Rintel
Note that commit dd0e198955 ('include: add nm-dbus-compat.h')
introduced this file from dbus sources ([1]). Hence, originally
the file is (like all of dbus sources) dual-licensed under GPL-2.0+
and Academic Free License 2.1 (AFL-2.1). That makes it problematic to
change the license of this file to LGPL also because of the old history
of the file.
Instead, drop everything from the header except the bits that we
actually use. I claim the remainder is trivial and only contains
defines for documented D-Bus API. I don't think that the remainder
is copyrightable and hence get rid of the copy-right notice and the
GPL license.
[1] 39ea37b587/dbus/dbus-shared.h
