The gintptr data type is already used in iterator. Keep versions in sync
to avoid issues when one of them overflows while the other did not
(yet). Since integer overflows could eventually happen anyway, make
version unsigned.
The size attribute is actually a "capacity" instead of a size in a more
classical sense: It doesn't represent the byte size but the amount of
elements within the hash table.
This is always a power of two, capped at 32 bit. This limit is required
to satisfy the support of converting a GHash into a GArray, which is
capped at G_MAXUINT elements.
Treat the size as capacity and bring it to the same data type as nnodes
and other element counters for better performance.
While at it, turn all variables taking the value of size into a guint
as well.
Closes: #672
Having unsigned values guarantees that g_hash_table_find_closest_shift
will never loop endlessly. Also make sure that it's impossible to
evade the sanity check of size in g_hash_table_set_shift. Since the
value will be an index, do not allow negative values.
Helps: #672
If nnodes value is very large, multiplying by 4 could overflow its guint
data type. Instead, first check that size is not 0, subtract by one, divide
by 4 and then check if that value is larger or equal to nnodes.
Flipping these checks has a nice advantage for small hash tables.
Helps: #672
Using the builtin multiplication checks leads to less instructions used
for these common functions (true for clang as well as gcc on x86_64).
Also, from a C perspective, the result is re-used, making code audits
easier.
With these adjustments, building with clang leads to no warnings:
- The "{ NULL }" statement could be replaced with "{ 0 }" to satisfy
clang, but this way it's explicitly filling all fields
- Even though "i" is not read with these g_array_binary_search calls,
it rightfully should be set
He’s been listed in `docs/CODEOWNERS` as one of the co-maintainers for a
long time, and it seems like an administrative oversight that the right
record was never added to `glib.doap` to give the GitLab maintainer
rights bit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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.
IApplicationActivationManager implements the IForegroundTransfer interface,
which lets us specify if the launched app is allowed to create a window
that steals focus (assuming our process has such ability). By default that
setting is disabled, so launched apps appear in the background and do not
get focus.
See XDG activation (Wayland) and the Startup notification specification (X11)
for equivalent functionality on Unix.
Support for focus-stealing can be set in GAppLaunchContext subclasses like
GdkAppLaunchContext, see gdk_app_launch_context_set_timestamp [1].
[1] https://docs.gtk.org/gdk4/method.AppLaunchContext.set_timestamp.html
GdkAppLaunchContext for Wayland / X11 fetch an opaque token
from the compositor.
On Windows, the system doesn't give you any token. Instead,
the token is implicit, and you can pass that to other
processes via dedicated APIs like AllowSetForegroundWindow.
Due to that, we use an internal format for startup-notify-id
that lets us check what to pass to activated apps.
Currently, the `GDesktopAppInfo` constructors return an error if
validity checks for the `Exec=` line, or other lines, fail. However,
they were ignoring the validity checks done at the `GKeyFile` level, for
invalid UTF-8 or string escaping.
It seems consistent to error out for those too, rather than pretending
that the key file line wasn’t set at all (i.e. treating it like `NULL`).
Spotted by Daniel Kondor.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3771
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>
