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>
Mention that Visual Studio 2019 16.8.x is the minimum supported
version, and Visual Studio 2013 or earlier is no longer supported.
Also mention that Python 3.7.x or later is required.
Visual Studio 2015/2017 are supported by best-effort.
Let people know how ARM64 builds can be done with Visual Studio, and
mention that using Windows SDK 10.0.22621.0 is required for Visual
Studio 2019 ARM64 builds.
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>
Fedora 39 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 41.
systemtap-sdt-dtrace needs to be installed separately (for the `dtrace`
binary), as it appears to have been split out of some other package.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation.
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.
He’s made a lot of detailed contributions recently, and has a good
understanding of large parts of GObject.
I‘ve asked him (by private email) if he’d agree to be added to the
co-maintainers list, and he said he’d be pleased to.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
Definitions in definition lists in most markdown implementations,
including the GitLab one, support laziness for the definition text
(https://spec.commonmark.org/0.31.2/#lazy-continuation-line).
As a result, each defined term would be collapsed into preceding definition.
To fix this, definitions need to be separated by blank line.
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.
wiki.gnome.org has been retired but for some reason none of the old
pages were given HTTP redirects, so everyone has to update all their
links manually everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
