The identifiers and types in Gio-2.0 that are used for backward
compatibility purposes in order to keep code importing Gio and using
platform-specific API are actually breaking the platform-specific
introspection data, because the introspection scanner favours types
found inside dependencies as opposed to types with the same name found
inside the current namespace.
In practice, the backward compatibility hack of keeping duplicate types
inside Gio-2.0 is effectively preventing people from using GioUnix-2.0
and GioWin32-2.0.
We cannot change the introspection scanner, because that could have
unforeseen results across the stack.
We cannot remove the symbols and bump the namespace version of Gio and
friends to 3.0, unless we keep generating known-to-be-broken 2.0
versions of all the namespaces. It also won't solve the issue of code
loading Gio without specifying a version, because that always imples
using the latest version of the namespace, which means backward
compatibility would still need an explicit opt in.
In practice, the only reasonable way forward is to break backward
compatibility, and remove the duplicate symbols and identifiers from
Gio-2.0, as we should have done in the first place.
Fixes: #3744
Spotted by Vincent Fazio. The old flag value was incorrectly used
instead of the new one when testing to see which flags were set. Likely
a typo.
This will never have worked, because the first few lines of the function
assert that the old flag value is not set.
Includes a unit test so we don’t regress on this in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Reported-by: Vincent Fazio <vfazio@gmail.com>
Fixes: #3768
`GStrv` can only be used with `g_auto`, not `g_autoptr`.
Guess who just copied and pasted this code example and found it didn’t
compile?
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If g_log_structured is called recursively with more than 16 fields,
then n_fields is larger than the stack array, leading to an eventual
read overflow into the message buffer.
Either the message can be properly prepared by an attacker or many
bytes are left uninitialized (and potentially prepared through
previous function calls by the attacker), which could lead to
information leaks through logs.
Since such a recursive overflow can only be triggered with test
code (or users explicitly supplying G_LOG_FLAG_RECURSION), this is
no security threat.
Closes#3760
Multiplying a guint value with BIG_ENTRY_SIZE (8) can overflow the guint
data type if size reaches 2^29. Use the correct size_t type for 64 bit
systems to support such allocations.
A 32 bit system should fail its reallocation way earlier before reaching
such a large "size", i.e. item count, especially when reallocating.
Also, it would multiply with 4.
Closes#3724
This is needed to ensure that the pointer is not removed
by an optimization pass. Theoretically, we'd have to add
both 'used' and 'retain' attributes, however for PE targets
'used' includes the effect of 'retain' [1], and GCC warns
if 'retain' is used in PE targets.
Fixes the constructor test in LTO builds.
[1] https://reviews.llvm.org/D96838
This might be the default, but let’s be explicit about it, since the
non-nullability of the return value is explicitly mentioned in the prose
of the documentation.
This contrasts with the `(nullable)` on the return value of
`g_main_context_get_thread_default()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In the case where mimeapps.list is a symlink, gio-issued updates would
overwrite the file, destroying the symlink in the process.
Instead, this approach recursively follows mimeapps.list symlinks
and overwites the contents of the final file instead.
Closes#3579
The g_array_binary_search function does not necessarily return the index
of the first instance within the array. If the sentence is read as "the
first encountered instance", then it would be correct but not helpful.
Drop the statement and keep the code as it is.
It’s possible for the dispatch of the timeout source to race with the
finalisation of the `GMemoryMonitorPoll`, given that the timeout is run
in the GLib worker thread.
Protect against that by holding a thread-safe weak ref on the
`GMemoryMonitor` in the callback data.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3758
