1. NetworkManager-1.14.0/shared/nm-utils/nm-shared-utils.c:1242: value_overwrite: Overwriting previous write to "ch" with value from "v".
 2. NetworkManager-1.14.0/shared/nm-utils/nm-shared-utils.c:1239: assigned_value: Assigning value from "++str[0]" to "ch" here, but that stored value is overwritten before it can be used.
 #  1237|   				if (ch >= '0' && ch <= '7') {
 #  1238|   					v = v * 8 + (ch - '0');
 #  1239|-> 					ch = (++str)[0];
 #  1240|   				}
 #  1241|   			}

Don't assign ch when it is going to be overwritten.

keyfile already supports omitting the "connection.id" and
"connection.uuid". In that case, the ID would be taken from the
keyfile's name, and the UUID was generated by md5 hashing the
full filename.

No longer do this during nm_keyfile_read(), instead let all
callers call nm_keyfile_read_ensure_*() to their liking. This is done
for two reasons:

 - a minor reason is, that one day we want to expose keyfile API
   as public API. That means, we also want to read keyfiles from
   stdin, where there is no filename available. The implementation
   which parses stdio needs to define their own way of auto-generating
   ID and UUID. Note how nm_keyfile_read()'s API no longer takes a
   filename as argument, which would be awkward for the stdin case.

 - Currently, we only support one keyfile directory, which (configurably)
   is "/etc/NetworkManager/system-connections".
   In the future, we want to support multiple keyfile dirctories, like
   "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles".
   Here we want that a file "foo" (which does not specify a UUID) gets the
   same UUID regardless of the directory it is in. That seems better, because
   then the UUID won't change as you move the file between directories.
   Yes, that means, that the same UUID will be provided by multiple
   files, but NetworkManager must already cope with that situation anyway.
   Unfortunately, the UUID generation scheme hashes the full path. That
   means, we must hash the path name of the file "foo" inside the
   original "system-connections" directory.
   Refactor the code so that it accounds for a difference between the
   filename of the keyfile, and the profile_dir used for generating
   the UUID.

In general, it's fine to pass %NULL to g_free().

However, consider:

    char *
    foo (void)
    {
        gs_free char *value = NULL;

        value = g_strdup ("hi");
        return g_steal_pointer (&value);
    }

gs_free, gs_local_free(), and g_steal_pointer() are all inlinable.
Here the compiler can easily recognize that we always pass %NULL to
g_free(). But with the previous implementation, the compiler would
not omit the call to g_free().

Similar patterns happen all over the place:

    gboolean
    baz (void)
    {
        gs_free char *value = NULL;

        if (!some_check ())
            return FALSE;

        value = get_value ();
        if (!value)
            return FALSE;

        return TRUE;
    }

in this example, g_free() is only required after setting @value to
non-NULL.

Note that this does increase the binary side a bit (4k for libnm, 8k
for NetworkManager, with "-O2").

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/21

[thaller@redhat.com: fix generated clients/common/settings-docs.h.in file
   and fix wrong change in src/systemd/src/libsystemd/sd-event/sd-event.c]

Add a configure option to disable eBPF support in n-acd.

Note that, even if eBPF is not supported, n-acd requires a kernel >
3.19, which means that the setsockopt(..., SO_ATTACH_BPF) option must
be defined. To allow building on older kernels without modifying the
n-acd code, we inject the SO_ATTACH_BPF value as a preprocessor define
in the compiler the command line.

Adapt the nm-acd-manager.c code to the new API and also tweak build
options to the new project structure.