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().
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.type:
Only 'ovs-port' connections can be enslaved to 'ovs-bridge'
nm_streq0() is not good here. It fails (with a wrong error message) even
when the slave_type is not set, which it shouldn't since slave_type can
be normalized. The real problem is the lack of the master property.
This fixes the condition:
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.master:
A connection with a 'ovs-port' setting must have a master.
Corrects the error message:
$ nmcli c add con-name br0 type bridge
$ nmcli c add type ovs-port ifname ovsport0 parent br0
Error: Failed to add 'bridge-slave-ovsport0' connection: connection.slave-type:
'ovs-port' connections must be enslaved to 'ovs-bridge', not 'bridge'
And gets rid of a confusing nm_streq0 use when comparing the type, since
at that point type must not be NULL anymore.
Fixes: 4199c976da
A naive code compliance checker. Invoke directly:
contrib/scripts/checkpatch.pl 0001-switch-comments-to-klingon.patch
contrib/scripts/checkpatch.pl hello.[ch] world.c
Use from a commit hook:
echo 'git format-patch --stdout -1 |contrib/scripts/checkpatch.pl || :>' \
>.git/hooks/post-commit
Or view the documentation with "perldoc contrib/scripts/checkpatch.pl"
Note how "nm-glib.h" uses _nm_printf() macro, which is defined in
"nm-macros-internal.h". There are many ways how to solve that
problem.
For example, we could define certain _nm_*() macros in "nm-glib.h"
itself. However, that is a bit awkward, because optimally "nm-glib.h"
only provides functions that are strictly related to glib compatiblity.
_nm_printf() is used by "nm-glib.h" for its own implementation, it should
not provide (or reimplement) this macro.
We solve this instead by enforcing what NetworkManager already does.
NetworkManager never includes "nm-glib.h" directly, instead
"nm-macros-internal.h" is the only place that includes the glib compat
header. It means, you cannot use "nm-glib.h" without
"nm-macros-internal.h". But that is a reasonable compromise, with
respect to granularity. The granularity at the moment is: if you use
anything from "shared/nm-utils", you almost always need at least
"nm-macros-internal.h" header (and automatically also get "nm-glib.h"
and "gsystem-local-alloc.h"). It's not intended, to use "nm-glib.h"
directly.
This makes "nm-glib.h" an implementation detail of "nm-macros-internal.h"
and it only exists to separate code that is related to glib compatibility to
its own header.
In commit 8a46b25cfa, NetworkManager
bumped its glib dependency to 2.40 or newer.
"nm-glib.h" header is precisely the compatiblity implementation that we
use to cope with older glib versions. Note, that the same implementation
is also used by applet and VPN plugins.
However, applet and VPN plugins don't yet require 2.40 glib. Also,
they don't yet require NetworkManager 1.12.0 API (which was the one
that bumped the glib requirement to 2.40). Hence, when "nm-glib.h"
is used in applet or VPN, it must still cope with older versions,
although, the code is not used by NetworkManager itself.
Partly revert 8a46b25cfa so that nm-glib.h
again works for 2.32 or newer.
The same is true, also for "nm-test-utils.h", which is also used by
applet and VPN plugins.
The function nmc_print() receives a list of "targets". These are essentially
the rows that should be printed (while the "fields" list represents the columns).
When filling the cells with values, it calles repeatedly get_fcn() on the
column descriptors (fields), by passing each row (target).
The caller must be well aware that the fields and targets are
compatible. For example, in some cases the targets are NMDevice
instances and the target type must correspond to what get_fcn()
expects.
Add another user-data pointer that is passed on along with the
targets. That is useful, if we have a list of targets/rows, but
pass in additional data that applies to all rows alike.
It is still unused.
