C casts unconditionally force the type, and as such they don't
necessarily improve type safety, but rather overcome restrictions
from the compiler when necessary.
Casting a void pointer is unnecessary (in C), it does not make the
code more readable nor more safe. In particular for g_object_new(),
which is known to return a void pointer of the right type.
Drop such casts.
sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i
./contrib/scripts/nm-code-format-container.sh
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>
Seems with LTO the compiler can sometimes think that thes variables are
uninitialized. Usually those code paths are only after an assertion was
hit (g_return*()), but we still need to workaround the warning.
Kernel (sysfs) and iproute2 only use numbers for the multicast_router
option. It's confusing that we name the options differently. Anyway,
that cannot be changed anymore. Clarify the meanings in the
documentation.
https://bugzilla.redhat.com/show_bug.cgi?id=1845608
This does not match kernel behavior. You seem to be able to configure
multicast_snooping=auto,enabled with multicast_snooping off just fine.
Possibly this constrained was inspired by `ip link`, which says:
mcast_router MULTICAST_ROUTER - set bridge's multicast router if IGMP
snooping is enabled.
But kernel doesn't enforce this:
ip link delete br0 2>/dev/null; \
ip link add br0 type bridge mcast_router 1 mcast_snooping 0; \
grep ^ /sys/devices/virtual/net/br0/bridge/{multicast_router,multicast_snooping}
gives:
/sys/devices/virtual/net/br0/bridge/multicast_router:1
/sys/devices/virtual/net/br0/bridge/multicast_snooping:0
We probably should not implement additional constrains on top of what
kernel does, if the conditions are that obscure.
Fixes: e01d3b4c2b ('nm-setting-bridge: add 'multicast-router' bridge option')
Hide the object and class structures from public API.
This is an API and ABI break, but of something that is very likely
unused.
This is mainly done to embed the private structure in the object itself.
This has benefits for performance and debugability.
G_PARAM_CONSTRUCT cause to explicitly initialize the property during
object construction. This is an unnecessary overhead that we can easily
avoid.
The overhead is because G_PARAM_CONSTRUCT parameters are always set with
g_object_set() before calling constructed(). Even if they are not specified
during g_object_new(), in which case it calls set with the property's default
value. This also requires g_object_new() to iterate all properties to
find and sort the construct properties.
NMSetting are supposed to be simple classes. They don't need to have
their properties initialized before object construction completes.
Especially if the default values are NULL or zero, in which case there
is nothing to do. If the default value is not NULL or zero, we need
to initialize the field instead in the nm_setting*_init() function.
