The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.
A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).
This causes the following issue, if we have:
typedef enum
{
G_ZERO,
G_ONE,
G_TWO
} GFoo;
struct _GBar
{
GFoo foo : 2;
};
and then assign bar.foo = G_TWO and read it back, it will have the
expected value of 2 (aka G_TWO) on GCC, but a value of -2 (not matching
any of the enum variants) on MSVC.
There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.
This corresponds to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6467
in GTK.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This triggered a warning from the CHERI compiler since the struct contains
a `void *` but `__attribute__((aligned(8))` reduced alignment to less than
the `void *` alignment (which is 16 for Arm Morello).
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Round-tripping pointers via gsize is not guaranteed to work (the C standard
only requires this for (u)inptr_t) and in fact breaks on CHERI-enabled
systems such as Arm Morello where pointers are 128-bits but size_t is 64.
This means the current casts would strip the high bits of the pointer and
return a non-dereferenceable value. Fix this by casting the operand that
holds the pointer to guintptr instead of gsize.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
This is required for CHERI systems such as Arm Morello, where gsize is
not large enough to hold a pointer. For all other architectures this
should not result in any functional changes since gsize is already the
same size (and I believe for most architectures even the same type)
as guintptr.
This is fully ABI compatible with all currently supported architectures
and should also be fully API compatible except for some rather unlikely
examples such as someone happening to use something like
`decltype(g_atomic_pointer_add(&a, 0))` in a C++ context where it
changes name mangling of some function.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Use a gpointer* instead of a gsize* as the g_atomic_pointer_* argument.
This is required for architectures such as Arm Morello where gsize is
64 bits but gpointer is 128 bits.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
If no error with -Werror=sign-conversion, the resulting object file
does not differ from compilation without -Werror=sign-conversion.
So the -Werror argument is now applied directly to string.c and testing.c.
Finally, the currently specific -Werror targets string-macro and
testing-macro are removed.
We can't easily use g_autofd with g_unix_open_pipe, because its
parameter is an array of two fds that both need closing. Add an inline
convenience wrapper providing the obvious semantics.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_clear_fd() is documented to be async-signal safe whenever the
fd is either negative or valid (which it should be here) and the error
is NULL (which it always is here).
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's not very likely, but there is a small chance that an
incoming signal could disturb the non-blocking read calls in
g_wakeup_acknowledge, leading to a subsequent spurious wake up.
This commit addresses the problem by doing the usual EINTR
loop (which is already present on the write side incidentally)
Previously, this would loop as long as read() got the expected number of
bytes back, which is 8. That means every successful read() of the eventfd
would perform an additional syscall() as a followup.
This is not ideal because eventfd (unless used as an EFD_SEMAPHORE) will
reset the counter as part of the read(). So that means that we either do
an additional throw-away syscall() or potentially race against a producer
generating new events before this change.
Currently the GSourceList has it's own allocation plus a secondary
allocation for the GList which contains it (from GMainContext). Not only
are these a pointer chase, but they are on separate cachelines too. Without
changing the code much we can at least keep things on the same cacheline
so that the pointer chase matters less.
Since the GList becomes embedded in the GSourceList you can use a
g_queue_unlink() directly removing the link without traversing the GList
like was done before.
Furthermore, we can simplify some code with g_queue_push_tail_link()
instead of some extra branching.
I'm not aware of any platforms where this is a problem in practice, but
it's definitely nonportable and doesn't hurt to document it.
I wonder about CHERI....
This should not result in any functional changes, but will eventually
allow glib to be functional on CHERI-enabled systems such as Morello.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
These functions can be used to initalize pointer-type variables rather
than a gsize. This is required to support CHERI-enabled platforms where
gsize cannot be used to store pointers. Follow-up changes will migrate
the uses of g_once_init that store pointers to the new API
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
One test key was serving two purposes, which meant tests for it couldn’t
be separated out. It was testing escape-at-end-of-line and also
invalid-escape.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3098
This reverts commit 4a96727642.
It was a temporary workaround to prevent disruption to apps late on in
the 2.78 cycle. Since we’re now early in the 2.80 cycle, let’s revert
the workaround and allow apps more time to fix their error handling for
`GKeyFile`.
Fixes: #3098
Commit 0b114b2687 accidentally made the
tests only pass on systems running in a UTC timezone, as it checked the
local timezone `%Z` format against `UTC`.
This happens to pass on all the GLib CI runners except the macOS one,
which is running under CET.
Make the formatting tests timezone-independent by running them with UTC
datetimes. There’s already a separate test for checking that `%Z` works
correctly in a non-UTC timezone (`test_z`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3611#note_1859208
It’s not actually needed on any platform, and causes compilation
problems on platforms where it’s not available.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3111
The Comment field provides a user-visible description of the app,
which usually contains generic words ("and", "or", "not", "is", ...)
that add noise when used for search.
It made some sense to match against the field as a fallback for
Keywords, before that key was well established. However that key
has been around for years now, so hopefully every app where additional
terms are helpful uses it by now.
With that, the downside of added noise outweighs the benefit, so
it's time to stop matching on comments.
