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
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
This should ensure that all editors which support
https://editorconfig.org/ use 2-space indentation with spaces (not tabs)
by default.
This isn’t a full specification of the GLib coding style (see
https://gitlab.gnome.org/GNOME/gtk/blob/HEAD/docs/CODING-STYLE.md for
that), but is a correct subset of it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
`g_settings_reset()` changes the value of the setting to `NULL`;
`add_to_tree()` was not handling that correctly.
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
Add missing (nullable), and use 2-space indentation to avoid markdown
pre-formatted blocks when unwanted.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As this would have undesirable consequence.
Quoting Philip Withnall:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2305#note_1294729:
The documentation never said anything about accepting absolute paths,
so any code which is relying on that is relying on undocumented
behaviour. We’re allowed to change that.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
