These cleanup macros are unused by NetworkManager code. Note that
since "shared/nm-utils" is used by applet and VPN plugins, theoretically,
they could be used there. I didn't check that, but breaking API of
"shared/nm-utils" is fine (as long as we catch it with a compilation
error).
Historically, we use libgsystem's gsystem-local-alloc header and their
"gs_*" macros. However, they are not really our style and don't have
a nm-prefix (like the rest of our code). We keep the gs_ names, because
they are wildly used and because we wanted to keep gsystem-local-alloc
in sync with upstream (which is no longer the case).
Our own cleanup macros are always called "nm_auto_*". So, at least
for the unused "gs_*" macros, rename them to "nm_auto_*".
Don't drop them, despite they being unused. The reason is, that we should
make use of cleanup functions more eagerly. Dropping them now -- because
they are momentarily unused -- hampers using them in the future. We
often don't use the cleanup macros at places where I think we should,
so by dropping them, we hamper future use.
Drop unused "gs_fd_close" macro, now that we no longer care about keeping
"gsystem-local-alloc.h" header in sync with (unmaintained) upstream.
Also, our own "nm_auto_close" macro should be preferred, because
- it preserves errno
- it uses nm_close(), which asserts against EBADF.
We used to build with -std=gnu89 so commit 1391bdfa61
added a local patch to systemd code to avoid compilation error due to
missing __STDC_VERSION__ define.
In the meantime, since commit ba2b2de3ad
and commit b9bc20f4da, we also use -std=gnu99
and thus __STDC_VERSION__ is defined.
Revert our local modification.
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
When developing, we usually do in-tree-builds, so that case is
already better tested in every-day usage. It makes sense for
travis to test the less-well-tested case: the out-of-tree
build with autotools.
1) the command line gets shorter. I frequently run `make V=1` to see
the command line arguments for the compiler, and there is a lot
of noise.
2) define each of these variables at one place. This makes it easy
to verify that for all compilation units, a particular
define has the same value. Previously that was not obvious or
even not the case (see commit e5d1a71396
and commit d63cf1ef2f).
The point is to avoid redundancy.
3) not all compilation units need all defines. In fact, most modules
would only need a few of these defines. We aimed to pass the necessary
minium of defines to each compilation unit, but that was non-obvious
to get right and often we set a define that wasn't used. See for example
"src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
This question is now entirely avoided by just defining all variables in
a header. We don't care to find the minimum, because every component
gets anyway all defines from the header.
4) this also avoids the situation, where a module that previously did
not use a particular define gets modified to require it. Previously,
that would have required to identify the missing define, and add
it to the CFLAGS of the complation unit. Since every compilation
now includes "config-extra.h", all defines are available everywhere.
5) the fact that each define is now available in all compilation units
could be perceived as a downside. But it isn't, because these defines
should have a unique name and one specific value. Defining the same
name with different values, or refer to the same value by different
names is a bug, not a desirable feature. Since these defines should
be unique accross the entire tree, there is no problem in providing
them to every compilation unit.
6) the reason why we generate "config-extra.h" this way, instead of using
AC_DEFINE() in configure.ac, is due to the particular handling of
autoconf for directory variables. See [1].
With meson, it would be trivial to put them into "config.h.meson".
While that is not easy with autoconf, the "config-extra.h" workaround
seems still preferable to me.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html
Also, "src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-common.h"
already has a define IFCFG_DIR, but with a different value.
We shouldn't name different things the same.
Fedora is removing gcc from the default build-root [1], hence
require it.
Actually, we already have a "BuildRequires: libtool", which has a
dependancy on gcc and we already got it implicitly. Just make it
explicit.
[1] https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
The function is supposed to return the IPv4 address as 32 bit integer in
network byte order (bit endian). The ip4_addr_ne32() name is confusing,
because "ne" commonly stands for "native endianness".
Compare also "unaligned.h" and unaligned_read_ne32(), which also
stands for native endianness (host order), not network order (big
endian).
Rename.
We previously kept any acd-manager running if the device was
disconnected. It was possible to trigger a crash by setting a long
dad-timeout and interrupting the activation request:
nmcli con add type ethernet ifname eth0 con-name eth0+ ip4 1.2.3.4/32
nmcli con mod eth0+ ipv4.dad-timeout 10000
nmcli -w 2 con up eth0+
nmcli con down eth0+
After this, the n-acd timer would fire after 10 seconds and try to
disconnect an already disconnected device, throwing the assertion:
NetworkManager:ERROR:src/devices/nm-device.c:9845:
activate_stage5_ip4_config_result: assertion failed: (req)
Fixes: 28f6e8b4d2
At various places, use the correct type for the pointer, this
allows the compiler to be more helpful.
For gs_free, gs_unref_object, and nm_auto_free, the pointer type is
of course still 'void *'.
This catches wrong uses like
gs_strfreev char *wrong1 = NULL;
gs_strfreev const char **wrong2 = NULL;
gs_free_error GError **p_error = NULL;
gs_unref_array GPtrArray *ptr_array = NULL;
Note that long time ago we copied "gsystem-local-alloc.h" header
from libgsystem library. Until now, we didn't apply any local
modification to this file, to keep it in sync with upstream.
However, upstream libgsystem is not maintained anymore, so there
is no reason to stay in sync with upstream.
This really is the same as gs_strfreev / g_strfreev().
However, the difference is, that the former has the notion
of freeing strv arrays (char **), while this in general
frees an array of pointers. Implementation-wise, they are
the same.
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
Don't use the integer type before signed/unsigned, but the
other way around. That is,
unsigned long var;
instead of
long unsigned var;
Also, just use "unsigned" instead of "unsigned int".
Tabs are not only wrong after a space, they are always
wrong if they don't appear at the beginning of a line.
That would happen usually, when trying to align multiple
lines like
enum {
VALUE1 = 1;
OTHER_VALUE = 2;
};
When doing that, the alignment will only be correct, if the
reader later uses the same tab-width. Note that in NetworkManager
we recommend the tab-width to be 4 characters, but with our "smart
tab" indentation style, it wouldn't actually matter and the reader
is free to choose any other tab-width -- as long as we don't use
non-leading tabs.
Don't allow non-leading tabs.
We should not use glib typedefs for basic C types char, short, int,
long, float or double. We commonly do not use them, so enforce
consistency.
That is not true for typedefs like guint, which we commonly use
because it's shorter typing than "unsigned int" (or "int unsigned"
or "unsigned"). Whether or not to use guint is left undecided at this
point.
get_prop_type() cannot ever return "gchar", because it only returns
values from "dbus_type_name_map" or for enums it has the form
"%s (%s)" % (pspec.value_type.name, prop_type)
Another reason why get_prop_type() cannot ever return a "char" type,
is because of what get_prop_type() does. get_prop_type() only returns
types based on the D-Bus type of the property, and on D-Bus there is
no fundamental type for a one-character string. There is either a
(UTF-8 encoded) string, or integer values of varying sizes. But in
terms of unicode, a 'char' type makes little sense on D-Bus. And neither
does it for get_prop_type().
