gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
This allows the flag to allow interactive auth to be set. Previously, it
was unconditionally unset.
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
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400