We don't want to update this function in case some crusty old third party
code might be relying on its current behavior.
Also, it is deprecated anyway and no code should be using it.
Use SetThreadUILocale() to set the UI locale to English (United States)
(en-US), and use SetConsoleOutputCP() to set the code page to en-US (codepage
437) so that g_win32_error_message() will always return the error messages in
English and ensure that the program runs in English as well, so that we
can ensure that the expected error message string can match up
regardless of the languge version of Windows that is running.
The code has warned about this since commit 6d9f874330 in 2011.
glibc 2.37 has just started asserting if a `NULL` format is passed to
`sprintf()`, which caused the existing GLib workaround to start
asserting too.
Bite the bullet and upgrade the warning for `format != NULL` to a
critical warning. Projects have had 12 years to fix their code.
The original bug reports
(https://bugzilla.gnome.org/show_bug.cgi?id=660371,
https://bugzilla.gnome.org/show_bug.cgi?id=560482) are actually both
about a domain which is `0`, rather than a format which is `NULL`, which
gives some confidence that this change will actually impact very little
third party code.
Since it doesn’t currently need changing, I have not touched the warning
about `domain != 0`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2913
While it’s not possible to build GLib with `-Wsign-conversion` enabled
(there are too many warnings), it would be useful to check that GLib’s
public headers can be used with `-Wsign-conversion` enabled, as some
projects want to do that. For example, dnf5 is built that way (see
issue #2919).
Add a simple regression test for this, by re-building the `gstring`
tests with `-Wsign-conversion` enabled. Since they include `glib.h`,
this will test all the public libglib headers by proxy.
Since this is a compile-only test, it doesn’t need to be installed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2919
It was assigning the two provided lengths to internal `int` variables.
Given that memory block lengths are typically a `size_t`, this will
usually result in a warning if `-Wsign-conversion` is enabled.
Given that the internal variables are passed to `memcmp()`, which takes
`size_t`, change them to `size_t` and add an explicit cast to avoid
warnings in future.
The alternative would be to mess around with defining `__l1` and `__l2`
to using `typeof()`, but that would lead to a complete mess with the
printf placeholders and probably cause more problems than it fixes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2919
The array is an array of bytes in this part of the test, so we need to
append a single byte. Previously we were reusing val (a size_t variable)
from earlier in the test, but because g_array_append_val passes the value
by reference, appending a multi-byte number to an array of bytes will
take the first byte of the number's memory representation, which has the
desired value on little-endian CPUs but is zero on big-endian, leading
to a test failure.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2918
Bug-Debian: https://bugs.debian.org/1031271
Signed-off-by: Simon McVittie <smcv@collabora.com>
It’s a private API, and is not meant to be exposed in the public API.
Since it’s only used internally within libglib, we don’t have to expose
it in the public symbol table, so drop the decorator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2876
It’s not meant to be exposed publicly yet (we’re not ready to stabilise
it), but it was incorrectly decorated with `GLIB_AVAILABLE_IN_2_76`.
We can’t remove the decorator and use it that way, as it’s called in
libgio, so we have to expose it using `GLIB_PRIVATE_CALL()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2876
For CHERI-enabled architectures such as Arm Morello we have to align the
GVariantIter to pointer alignment (16 bytes for Morello) but defining the
opaque struct as 16 gsize elements only aligns to 8 bytes.
This does not change the layout for existing architecutre since there
gsize is the same as guintptr.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
The code for SMALL_ENTRY_SIZE assumes pointers are no larger than 8 bytes,
so instead of trying to make it work disable the optimization for now.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Co-authored-by: Graeme Jenkinson <graeme@capabilitieslimited.co.uk>
Use guinptr instead if gsize. While this increases the structure size
for Morello, it is still only 256 bytes which should not matter for a
type where we expect few instances to exist at any given time.
This does not increase the size for existing architectures since gsize
is the same as guintptr for all of them.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Last field needs to be pointer-size to match GHashTableIter. This happened
to work for most architecture due to alignment padding/pointer size, but
for CHERI targets with 128-bit pointers RealIter ends up being smaller
than GHashTableIter.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
GObject-Introspection seems to become confused by the nested conditional
followed by an `#elif` clause for the outer conditional, and issues
this warning:
.../gtimezone.c:830: mismatched #elif defined (G_OS_WIN32)
Signed-off-by: Simon McVittie <smcv@collabora.com>
GObject-Introspection and gtk-doc both parse C headers using regular
expressions, so they can easily be confused by non-trivial conditions.
GObject-Introspection warns about this:
.../gstrfuncs.h:151: the __GI_SCANNER__ constant should only be used with simple #ifdef or #endif: #if !defined (__GTK_DOC_IGNORE__) && !defined (__GI_SCANNER__)
In this case it's very easy to convert the compound expression into
nesting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The sample code here wasn't a race-free version of the race-susceptible
anti-pattern, because it would have dereferenced a symlink automatically.
Fixes: 293b4923 "Clarify g_file_test() docs about TOCTOU bugs"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The canonical directory separator is a backslash, but some Windows APIs
allow either, interchangeably. Do the same here.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2914
Signed-off-by: Simon McVittie <smcv@collabora.com>
Glib does not yet have a well defined ABI/API for architectures
where gsize != guintptr (e.g. CHERI). To enable working on bringup
for new architectures this assertion can be disabled with
`-DG_ENABLE_EXPERIMENTAL_ABI_COMPILATION`.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2842
[smcv: Apply review comments from pwithnall]
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 da3fc59544f36e246cd7f5a198083203199d5127.
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.
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
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>
