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
A table size of 2**31 cannot be represented in a gint. Adjust
RealIter to use a guint for its current position to support the largest
power of two possible for a hash table size.
This makes sure that g_hash_table_iter_next does not trigger a signed
integer overflow, which would eventually lead to an out of boundary
read.
With input by Philip Withnall.
Helps: #672
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
The entry_is_big function checks if an entry fits into a so-called
small entry, i.e. into a guint. This optimizes space for hash tables
on 64 bit system with hash tables containing 32 bit entries.
This code actually checks if the highest 32 bits are set, which would
become an issue with CHERI and its 128 bit pointers.
Helps: #2842
`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>
