There is no reason to validate only in certain cases. Either we
validate, or we don't (always the same).
This is a change in behavior, but the cases should be sensible.
Most GObject properties default to FALSE/NULL/0. In that case, there
is no difference between setting the default or clearing the value.
During
if (_SET_FCN_DO_RESET_DEFAULT (property_info, modifier, value))
return _gobject_property_reset_default (setting, property_info->property_name);
it is correct to reset the default.
However for list-typed properties, we want to clear the list. So,
it should be
if (_SET_FCN_DO_SET_ALL (modifier, value))
_gobject_property_reset (setting, property_info->property_name, FALSE);
The VFs already can be parsed as plain number (to indicate the
ifindex). We should not also support accepting the plain number
as index to be removed.
Fixes: a2f12994b7 ('cli: add support for configuring SR-IOV')
$ nmcli connection modify "$PROFILE" -ipv4.addresses 1,3
Already before, nmcli would support removing items by index. But only
one number was supported.
- indexes are zero based (as before).
- duplicate indexes or indexes out of bounds are silently ignored.
Maybe certain properties should not support removal by index.
Use new ValueStrsplitMode "VALUE_STRSPLIT_MODE_STRIPPED".
Note that this is not exactly what we did before. For example, empty
tokens are now silently removed.
Also, we accept now whitespace as separators.
Have one function that gets all the nonesense right. "nonesense", because
we have inconsistent behaviors, and the function is supposed to help with
that.
set_fcn() and remove_fcn() are strongly related. They should accept
arguments in the same format, hence the parsing of the arguments should
be done at one place.
In fact, previously the parsing was separate, leading to ugly
inconsistencies:
$ nmcli connection modify "$PROFILE" +vpn.data x=y
$ nmcli connection modify "$PROFILE" -vpn.data x=y
Error: failed to remove a value from vpn.data: invalid option 'x=y'.
or
$ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24
$ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24
Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed.
Let set_fcn() handle set-default, set-all, add, and subtract.
Previously, set_fcn() could only append values. Now, pass on the modifier
so that it may append, set all, or reset the default.
These operations are strongly related and should be handled by the same
set_fcn() function.
It's usually not necessary, because _nm_utils_unescape_spaces()
gets called after nm_utils_strsplit_set(), which already removes
the non-escaped spaces.
Still, for completeness, this should be here. Also, because with
this the function is useful for individual options (not delimiter
separate list values), to support automatically dropping leading or
trailing whitespace, but also support escaping them.
A property-info can only have one property-typ-data. That means,
all functions (get_fcn(), set_fcn()) need to either take not
property-typ-data, or they must all accept the same.
That made it hard to mix _get_fcn_nmc_with_default() with setters
that do require a certain property-typ-data. Instead, move the
is_default_func() to the general portion, and let _get_fcn_gobject()
handle it.
Instead of having a trivial macro that defines a function, define the
function directly.
Having such a macro would make sense if DEFINE_REMOVER_OPTION() would do
the right thing and we would reuse the (preferred) implementation.
That's not the case, because these remove_fcn() implementations don't
mirror the way how set_fcn() splits and sets options. They are
inconsistent (wrong), and should will later get merged with set_fcn().
