How odd that such a macro does not exist yet. It seems like
the majorities of calls to g_slice_free() could be replaced
by this.
(cherry picked from commit dcdbe98406)
Sometimes these function may set errno to unexpected values like EAGAIN.
This causes confusion. Avoid that by using our own wrappers that retry
in that case. For example, in rhbz#1797915 we have failures like:
errno = 0;
v = g_ascii_strtoll ("10", 0, &end);
if (errno != 0)
g_assert_not_reached ();
as g_ascii_strtoll() would return 10, but also set errno to EAGAIN.
Work around that by using wrapper functions that retry. This certainly
should be fixed in glib (or glibc), but the issues are severe enough to
warrant a workaround.
Note that our workarounds are very defensive. We only retry 2 times, if
we get an unexpected errno value. This is in the hope to recover from
a spurious EAGAIN. It won't recover from other errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1797915
(cherry picked from commit 7e49f4a199)
(cherry picked from commit eec2740d71)
(cherry picked from commit 500f0b96ae)
Clang 3.4.2-9.el7 on CentOS7.6 complains about missing generic type match:
../dispatcher/nm-dispatcher.c:243:2: error: controlling expression type 'const Request *const' (aka 'const struct Request *const') not compatible with any generic association type
_LOG_R_D (request, "start running ordered scripts...");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 17dc6a9da6 ('shared: add _NM_ENSURE_TYPE_CONST()')
(cherry picked from commit 3d42b2f1fa)
The sole purpose of this is more type-safe macros.
An alternative solution would be to define a function instead of a
macro. But if the function is unused (currently!) you get a compiler
warning (on some compilers even when marking the function as "static
inline", if it's in the source file). A workaround for that would be
to mark the function as _nm_unused, or to use a macro instead.
_NM_ENSURE_TYPE_CONST() is to aid the macro solution.
(cherry picked from commit 17dc6a9da6)
From the files under "shared/nm-utils" we build an internal library
that provides glib-based helper utilities.
Move the files of that basic library to a new subdirectory
"shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
to "libnm-glib-aux.la".
Reasons:
- the name "utils" is overused in our code-base. Everything's an
"utils". Give this thing a more distinct name.
- there were additional files under "shared/nm-utils", which are not
part of this internal library "libnm-utils-base.la". All the files
that are part of this library should be together in the same
directory, but files that are not, should not be there.
- the new name should better convey what this library is and what is isn't:
it's a set of utilities and helper functions that extend glib with
funcitonality that we commonly need.
There are still some files left under "shared/nm-utils". They have less
a unifying propose to be in their own directory, so I leave them there
for now. But at least they are separate from "shared/nm-glib-aux",
which has a very clear purpose.
(cherry picked from commit 80db06f768)
