,,,for G_ALWAYS_INLINE and G_NO_INLINE, since the msvc::forceinline and
msvc::noinline attributes require C++-20 support, not just C++-11
support. This will avoid warning C5051 (unsupported attribute ...,
ignored) if pre-C++-20 was used.
The recent optimizations to gstring.h used G_ALWAYS_INLINE (meaning
'__forceinline' on Visual Studio) together with 'static inline', which
will cause warning C4141 indicating that 'inline' was used more than
once on the function.
Avoid this by temporarily disabling warning C4141 in gstring.h when
building the code that uses 'G_ALWAYS_INLINE'.
Fixes issue #2905.
All Unix CRTs examined: glibc, musl, BSDs, Apple libc, Android bionic
ignore unknown fopen () mode flags, so this flag can be added
unconditionally for Unix builds.
Only Windows CRT is intolerant of these, so the single case in
g_dbus_address_connect () where the fopen () call is shared between Unix
and Windows needs appropriate platform-specific handling.
Skipped the call sites in libcharset and xdgmime copylibs.
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
The `equal_func` closure can already have all required information
available without the item, and passing the item via the closure instead
of an explicit parameter is more natural for languages that have a
concept of closures that can capture variables.
This is a departure from our policy of using the minimum required Meson
version, but I think it might be worth a try to see if it fixes the
persistent intermittent build failures on these platforms due to what
looks like build dependency graph issues.
For example:
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579411
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2578792
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579220
- https://gitlab.gnome.org/pwithnall/glib/-/jobs/2588507
I was looking at trying to diagnose some of these failures in order to
potentially file bugs against Meson, but the first step is really to
test against the latest version of Meson. So here we are.
Crucially, our other CI jobs continue to use the minimum Meson version
required by GLib, so we continue to test that GLib builds with its
minimum dependencies. I do not plan to change that.
Also crucially, this MR continues to use a specific Meson version,
rather than asking `pip` to install the latest available. Doing that
could lead to unexpected regressions in future, and that’s not what
GLib’s CI is meant to be testing for.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They take too long and time out, and are not particularly useful to run
under valgrind because they aren’t designed to test code coverage.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
