If we are using libffi to trampoline then there is opportunity to cache
the ffi_call_plan introduced in newer libffi releases. A rather contrived
test introduced in the previous commit includes a basic performance test
that can compare between versions.
For my system, the average call time dropped from 200ns/call to 145ns/call
for cached GClosure. Since the previous version did no caching, the
uncached GClosure use was also just slightly slower around 205ns/call. For
the cached form (since it can reuse a global plan cache via GMutex) it
drops to 180ns/call. So that is 27.5% savings and a 10% savings in runtime
duration.
Closes: #4002
Co-authored-by: Philip Withnall <pwithnall@gnome.org>
msys2-clang64 noticed that the `spacing` variable was written to but
never read from. Indeed, this option has been a no-op since I
accidentally/deliberately broke it in commit
98e6ac788e.
Drop it, because nobody has complained about it breaking since 2022, and
I’m not sure about what the use case for it originally was meant to be.
See https://gitlab.gnome.org/pwithnall/glib/-/jobs/7171235
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
A synchronous call built over the GTask machinery may attach its
completion sources to the calling thread's thread-default main context,
reclaimed only once that context is iterated. A worker thread that never
iterates one accumulates a small allocation per call. See #4041.
Add a new flag to GMountMountFlags that allows callers to request
a read-only mount. This is needed by file managers (e.g. Thunar)
to allow users to mount removable drives as read-only.
The flag is passed through the GVolumeIface::mount_fn vfunc and
can be handled by volume monitor implementations (e.g. gvfs
udisks2) to pass the appropriate options to the underlying
mount mechanism.
Also add a --read-only / -r option to the gio mount CLI tool.
This adds `-DG_DISABLE_CLEANUP` to be able to manually disable
cleanup attribute. This is useful for situations like GTK or
GtkSourceView which must avoid introducing cleanup attributes
to continue compiling on MSVC.
I would expect this to commonly be used next to defines for
min/max allowed library versions.
g_type_ensure has a large comment saying _get_type shouldn't be
marked with G_GNUC_CONST because it has side-effects on the first
run, but it's OK if you consistently call g_type_ensure first.
Unfortunately, this isn't accurate. GCC trunk (observed at r17-1725-ge259a182e1f100)
now analyses points-to information more effectively and propagates its
findings, so it sees the function modifies some global state, concludes
that can't be possible (because of the const attribute), and deletes
the stores.
pure unfortunately is unsuitable for *_get_type too as it has a side-effect
(writes to global memory).
Mesa had a similar issue which I fixed recently [0]. glib and glibmm likely
want the (not-yet-implemented) 'idempotent' attribute instead [1]. In fact,
this exact problem is what motivated that request! :)
ebassi mentions an alternative to the current setup as well, using
atomics [2].
This problem has gone back many years but the compiler has finally
fully outsmarted us here, so give in.
[0] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42361
[1] https://gcc.gnu.org/PR32911
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4249#note_2583110
Fixes: https://gitlab.gnome.org/GNOME/glib/-/work_items/3984
Signed-off-by: Sam James <sam@gentoo.org>
This adds a new g_set_strv() that has been used in various GNOME projects
to help ensure that strv properties are changed with minimal notify()
emissions as well as reduce chances for UAF.
Additionally, g_set_strv_take() is provided to allow setting a GStrv
without making a copy of the provided string. Use this when you are
using API like g_strv_builder_end().
Fixes: #3907
When running setuid, ignore this auth mechanism and hence also the
`$G_DBUS_COOKIE_SHA1_KEYRING_DIR` environment variable.
This was considered as part of #2168 but determined at the time to not
be a problem.
It’s since been reported as a vulnerability. I don’t see how it can
realistically be exploited in practice:
- This D-Bus auth mechanism is strongly discouraged and iirc it’s only
kept around for use on Windows
- The setuid binary would have to be running as a D-Bus server in a
peer-to-peer configuration, which is very rare
- Even rarer to run it as setuid root, rather than as a system service
via a service manager
- And the configuration would have to force this auth mechanism to be
used instead of any more appropriate mechanism
That said, I don’t see any reason why we _shouldn’t_ ignore this
environment variable when setuid. ¯\_(ツ)_/¯ The fallback for
`$G_DBUS_COOKIE_SHA1_KEYRING_DIR` is to build the keyring path using
`$HOME`, but that is equally as susceptible to attacker modification
when running setuid, hence we disable the whole auth mechanism.
This brings GIO inline with what libdbus does.
Spotted by cavid.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.
ID: #YWH-PGM9867-164
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is like `g_set_str()`, but it takes ownership of the new string
passed in to it, so you can conveniently pass in the return value of
`g_strdup_printf()` (etc.) without additional memory management
boilerplate.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The description of the distinction between default and user signal
handlers leaves it a bit unclear whether any signal handler connected
within the class implementation can actually be a default signal
handler. The term "object method handler" is ambiguous, because all
signal handlers are bound to an object, but the default signal handler
is bound to the class.
We should also link the GSignalFlags values, now that we can point to
specific enumeration values.
In particular, point out that `G_ENCODE_VERSION()` needs to be used to
encode versions which are newer than the minimum GLib dependency of your
project.
Also add a code example for Meson.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
- Redid the old StarOffice-format drawing file in OpenDocument
format, and updated with two different `-light` and `-dark`
versions.
- Added color to the rectangles
- Bolded all of the text
- Added background transparency
- Exported both as `file-name-encodings-{light,dark}.svg`
- Tweaked in Inkscape to simplify SVG structure, scale to
fixed pixel sizes, align to page dimensions.
- Added License/Copyright data as Custom Document Properties
in OpenDocument sources, comments in SVG source.
- Federico Mena Quintero, uploader of the originals, is
credited in the `SPDX-FileCopyrightText` data, along
with myself.
- License chosen was `CC0-1.0`, because again I don't believe
these files are complex enough to actually be copyrightable.
- Added data for `.odg` files to `/.reuse/dep5` file, as
reuse can't extract license data from that format.
- Updated `character-set.md` and `glib.toml.in` to use
new SVGs in place of old PNG.
There are four `Unix.+` classes in `Gio-2.0.gir` which need to be
exposed in the `Gio-2.0.gir` docs because they are actually now
cross-platform (which is a move which has caused a lot of pain).
Change the code which filters out the rest of the `Unix.+` classes to
ignore these ones. The rest of the classes continue to be documented via
`GioUnix-2.0.gir`.
Changing the regexs for this involved a fun use of negative lookahead.
See https://gitlab.gnome.org/GNOME/glib/-/issues/3697#note_2459405
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3697
This documentation used to link to GLib’s TAP harness. However, the built-in
Automake support works fine, and is simpler to use. Hence, remove most of
the old documentation, and refer users to the Automake manual, adding just
one hint for use with GLib.
Port the rest of the document to gi-docgen syntax, so we don’t have to
track partially-ported files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
These symbols are documented in the {glib,gio}-{unix,win32}
documentation builds, and shouldn’t be duplicated in the main
documentation. It’s a historical (and unavoidable) accident that those
symbols are in the main GIR files.
If we don’t hide the symbols from the main docs build, we now run into
the problem of the `GioUnix` namespace not being known to gi-docgen
while building the `Gio` docs. This is because of the previous two
commits, which ported more of the `gunixmounts` documentation to
gi-docgen syntax. I don’t know of another way to fix this, other than to
hide the `GioUnix` symbols from the `Gio` docs build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
If `-Ddocumentation=true` is specified without
`-Dintrospection=enabled`, warn the user. They might expect the
documentation to be built, but it won’t.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It doesn’t list all mounts, only the ones you’d expect to see in a file
chooser sidebar.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3555
systemd 257 will now set `DEBUG_INVOCATION=1` in the execution context
of services which need to be debugged — for example if they’ve failed
and been restarted (and `RestartMode=debug`).
If we handle `DEBUG_INVOCATION=1` as being equivalent to
`G_MESSAGES_DEBUG=all`, then any processes using GLib’s default log
writer function (or `g_log_writer_default_would_drop()`) automatically
gains support for this feature.
See https://mastodon.social/@pid_eins/113548825942383777
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Provide examples of what they all represent, and expand on the
descriptions of them in a few places.
Move references to their equivalents from `GnomeVFS` to lower down in
the documentation, since `GnomeVFS` has been deprecated for many years
now, and is unlikely to be pertinent to most readers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
