mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-04 12:10:15 +01:00
shared/trivial: add code comment to explain NMUtilsEnumValueInfo consistency rules
This commit is contained in:
parent
a1f1b13f4f
commit
b18c9e44ed
1 changed files with 9 additions and 0 deletions
|
|
@ -64,9 +64,18 @@ _ASSERT_enum_values_info (GType type,
|
|||
* And then, when actually running against a newer library version where
|
||||
* @type knows the nick, we have this situation.
|
||||
*
|
||||
* Another reason for specifying a nick both in @value_infos and @type,
|
||||
* is to specify an alias which is not used with highest preference. For
|
||||
* example, if you add an alias "disabled" for "none" (both numerically
|
||||
* equal), then the first alias in @value_infos will be preferred over
|
||||
* the name from @type. So, to still use "none" as preferred name, you may
|
||||
* explicitly specify the "none" alias in @value_infos before "disabled".
|
||||
*
|
||||
* However, what never is allowed, is to use a name (nick) to re-number
|
||||
* the value. That is, if both @value_infos and @type contain a particular
|
||||
* nick, their numeric values must agree as well.
|
||||
* Allowing this, would be very confusing, because the name would have a different
|
||||
* value from the regular GLib GEnum API.
|
||||
*/
|
||||
g_assert (enum_value->value == value_infos->value);
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue