These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
glib.git/glib/garray.c: In function ‘g_array_new’:
glib.git/glib/garray.c:184:34: error: comparison is always true due to limited range of data type [-Werror=type-limits]
184 | g_return_val_if_fail (elt_size <= G_MAXSIZE / 2 - 1, NULL);
| ^~
glib.git/glib/gmacros.h:1090:25: note: in definition of macro ‘G_LIKELY’
1090 | #define G_LIKELY(expr) (expr)
| ^~~~
glib.git/glib/garray.c:184:3: note: in expansion of macro ‘g_return_val_if_fail’
184 | g_return_val_if_fail (elt_size <= G_MAXSIZE / 2 - 1, NULL);
| ^~~~~~~~~~~~~~~~~~~~
glib.git/glib/garray.c: In function ‘g_array_sized_new’:
glib.git/glib/garray.c:265:34: error: comparison is always true due to limited range of data type [-Werror=type-limits]
265 | g_return_val_if_fail (elt_size <= G_MAXSIZE, NULL);
| ^~
glib.git/glib/gmacros.h:1090:25: note: in definition of macro ‘G_LIKELY’
1090 | #define G_LIKELY(expr) (expr)
| ^~~~
glib.git/glib/garray.c:265:3: note: in expansion of macro ‘g_return_val_if_fail’
265 | g_return_val_if_fail (elt_size <= G_MAXSIZE, NULL);
| ^~~~~~~~~~~~~~~~~~~~
D-Bus has an upper limit on number of Match rules and it's rather easy to hit
with a big number of proxies with signal subscriptions. This happens with
NetworkManager with hundreds of devices or connection settings. By passing
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE to g_dbus_connection_signal_subscribe(), the
user can call AddMatch with a less granular match instead of a match per every
proxy.
Tests subsequently added by Philip Withnall.
Fixes: #1109
The documentation about validity did not match the code. Since the code
hasn’t changed in a long time (since 1998 or 2011), change the
documentation to match it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2520
It’s a programmer error for `NULL` to reach `is_group_name()` or
`is_key_name()`, so rework the preconditions so that all programmer
error checks are wrapped in a `g_return_if_fail()`. The coverage
scanning is set up to ignore anything inside that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_key_file_parse_key_value_pair()` checks that both of these are
non-NULL on entry, and they can’t be modified between then and here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should introduce no functional changes, but will remove an
unreachable branch in `g_key_file_locale_is_interesting()`:
`checked_locales` indicates whether `locales` has been initialised (and
it can be initialised to `NULL`), so there’s no point in checking
`locales` itself if `checked_locales` is checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead compare it inline. This should avoid a lot of allocations in key
files with lots of translations (such as desktop files).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This avoids allocating a copy of the value in the case that it’s for a
locale which is uninteresting.
This should speed up parsing of key files with large numbers of
translations, when only the translations for certain locales are wanted.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn’t affect performance in the normal case of a valid key file,
but does improve performance when handling largely-invalid key files.
oss-fuzz#31796
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This was harmless, as it was always +1 too long, so included the
trailing nul terminator. However, upcoming changes will start to use it
in a context where there is no nul terminator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The documentation wasn’t clear about whether it did that, or ignored nul
bytes and continued to `n` bytes regardless.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than looking for the group node by comparing each name in the
linked list of `GKeyFileGroup` instances, look up the `GKeyFileGroup` in
the hash table, then look up its `GList` node by pointer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As the groups are disambiguated by name via the `groups` hash table,
there is guaranteed to be at most one `GKeyFileGroup` instance per group
name, which means they can be compared for equality by `GKeyFileGroup`
pointer, rather than needing a `strcmp()`.
This speeds up key file parsing in all cases.
oss-fuzz#31796
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This allows it to be called on a substring of a larger string, without
having to allocate a nul-terminated copy of the substring with
`g_strndup()` before knowing that the key name is actually valid.
This speeds up parsing of highly invalid key files, but doesn’t affect
performance in the normal case of a valid key file.
oss-fuzz#31796
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
- Isolate the first meaningful paragraph, for gi-docgen's summary
- Describe get_object() as a binding API
- Fix reference to get_item() inside get_item_type()
It is exactly the same wrap as the one in WrapDB but with a different
name. That fix error when multiple projects uses pcre and they don't
have the same wrap name:
meson.build:1:0: ERROR: Multiple wrap files provide 'libpcre' dependency: pcre.wrap and libpcre.wrap
All these `gchar *`s are used as moving pointers into strings, being
incremented as the strings are parsed. They are never modified, so can
be `const`. This doesn’t speed anything up, but does allow removing some
casts and slightly improving type safety.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_check_setuid does more than setuid checks when using AT_SECURE.
Make sure that it is referenced in the error message to help
users debug in case or errors
Closes#2518
