nm_g_array_index() performs additional nm_assert() checks for
correctness.
In this case, it's pretty clear that the assertion will hold and that
the code is correct. Note that most of the time when having assertions,
we expect that they hold. Since nm_assert() is disabled in release
build, arguing that an assertion holds is not a strong argument against
having the assert (they are always supposed to hold, quite obviously so!).
The reason to change is that we should use the wrappers that perform
additional checks. Especially when the additional checks are nm_assert()
or static-asserts, as they are not present in release builds. To find
how well we are doing in this regard we can check `git grep -w
g_array_index`. If that gives many uses of the unchecked function, then
we cannot manually check them all to be really obviously correct.
Instead, we should not use g_array_index() and trivially see that all
array accesses are guarded by assertions.
"checkpatch.pl" also recommends against g_array_index().
Show a new field called "Valid values" in those properties that only
accept a limited set of values, like enums, ints with a valid range of
values, etc.
As there is some complex logic behind getting this information, this
logic has been put in nm-meta-setting-desc and nm-enum-utils so they can
be re-used, avoiding duplicity and errors. Some refactor has been done
in nm-meta-setting-desc in this direction, too.
nm_utils_enum_to_str() can print flags, that is, combinations of
powers of two integers.
It also supports nicks, for certain flags.
When we have a nick for value zero, then that requires special
handling. Otherwise, that zero nick will always show up in the
string representation, although, it should only be used if the
enum value is exactly zero.
(cherry picked from commit eec9efd989)
NM_STR_BUF_INIT() and nm_str_buf_init() were pretty much redundant. Drop one of
them.
Usually our pattern is that we don't have functions that return structs.
But NM_STR_BUF_INIT() returns a struct, because it's convenient to use
with
nm_auto_str_buf NMStrBuf strbuf = NM_STR_BUF_INIT(...);
So use that variant instead.
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
