On closer inspection, these are redundant with stricter assertions that I
added in commit bd1e2a98 "glib-init: Statically assert more facts about
standard types", which assert that sizeof (gintptr) == sizeof (void *).
As far as I can tell, a sufficiently pedantic interpretation of Standard
C doesn't actually require (u)intptr_t to be the same size as a pointer:
it only requires that pointers can be losslessly stored in a (u)intptr_t,
which a sufficiently pathological ABI could implement by having (for
example) 32-bit pointers and a 64-bit uintptr_t just to troll us. However,
I'm fairly confident that no practically useful ABI would do this,
and certainly nobody has complained about this assertion since 2020.
Similarly, Standard C might permit an ABI where 64-bit pointers have the
first 32 bits always-zero and therefore storing the remaining bits in a
32-bit uintptr_t is lossless, but again, that would be pathological.
This reverts commit da3fc59544.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Do not use 4-spaces indentation for return and argument descriptions, to
avoid getting rendered as preformatted blocks.
Annotate code examples with their language, for syntax highlighting.
Isolate the first paragraph to give a short description.
Do not show just what not to do: show what to do instead, otherwise
people won't know how to fix their code.
Make sure to link to an explanation of the TOCTOU class of bugs;
Wikipedia is as good a place as any.
Since gmodule-visibility.h is now a custom target and produced at
buildtime, it might not always exist in time for use in other source
files. This was the case for gio-inotify.
Add it as an additional source file to ensure in-time generation.
According to the docs, g_slice_free1() is supposed to do nothing if
@mem_block is NULL, but we still try to zero it in case we're using
g_mem_gc_friendly.
So avoid this case.
Closes: #2908
Since commit 45b5a6c0 GSlice is just a wrapper to g_malloc0/g_free, so
there's no point to use a different implementation for UNIXes vs
windows.
This reverts commit 3b7af4dd5d.
Currently, inbuf_size and outbuf_size are not documented as not
nullable, but they are expected to be so, which might lead to unexpected
crashes. Moreover, outbuf itself is also expected to not be null, so
this commit adds the appropriate GI annotations and early returns on
failed preconditions.
If libc supports `free_sized()`, this could mean that freeing slices is
a bit more performant. If not, it falls back to using `free()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If we are sorting something that is a multiple of sizeof(void*), we have
to ensure that we swap one pointer at a time since swapping using
sub-pointer-size stores invalidate the pointers (pointers have a hidden
validity tags that is invalidated when performing non-monotonic
operations such as storing only part of the pointers).
While touching this code also use G_ALIGNOF() instead of a macro that
is generated at configure time.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
We have to ensure that the memory location is sufficiently aligned to
store any object. This unbreaks the code for CHERI where using gsize
results in values that are only aligned to 8 bytes, but we need 16 byte
alignment for pointers. This is fully API/ABI compatible since amount
of padding before the actual allocation does not change for existing
architectures, only for CHERI.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
