The functionality of win32_keep_fatal_message was lost with commit
fb9df27776, which introduced the usage of
fputs instead of write. The write system call was wrapped with a macro
for Windows systems to keep fatal messages in an extra buffer.
For the record, the unused dowrite function was removed in commit
5400f4e128.
Reintroduce the functionality to fix this regression in a memory-safe
way.
The static variables win32_keep_fatal_message and fatal_msg_buf are only
used for Windows debug builds and those without G_WINAPI_ONLY_APP
defined.
These checks are already in place for consumer of fatal_msg_buf, so
extend their usage.
This helps scan-build not emit a ‘potential null pointer dereference’
error for calls to `require_internal()`:
```
Access to field 'message' results in a dereference of a null pointer (loaded from variable 'local_error')
```
See https://gitlab.gnome.org/GNOME/glib/-/jobs/5482526 for details of
the error.
I don’t think there is an actual null pointer dereference here.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For backward compatibility, we automatically load the GioUnix or
GioWin32 namespaces if the Gio namespace has been required.
Also ensures that the platform-specific library is loaded in tests
Co-Authored-By: Marco Trevisan (Treviño) <mail@3v1n0.net>
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
