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
Otherwise, the content of the buffer is thrown away when switching
from reading via a GDataInputStream to unbuffered reads when waiting
for the "BEGIN" line.
(The code already tried to protect against over-reading like this by
using unbuffered reads for the last few lines of the auth protocol,
but it might already be too late at that point. The buffer of the
GDataInputStream might already contain the "BEGIN" line for example.)
This matters when connecting a sd-bus client directly to a GDBus
client. A sd-bus client optimistically sends the whole auth
conversation in one go without waiting for intermediate replies. This
is done to improve performance for the many short-lived connections
that are typically made.
This reverts commit 27bee8fe5d.
Inevitably, despite testing the CI multiple times before merging commit
27bee8fe, the CI is now failing again in the `socket` test due to (what
I continue to assume is) the kernel regression:
https://gitlab.gnome.org/martinpitt/glib/-/jobs/2585332
In order to unblock development on `main` expediently, I guess I’ll just
revert the revert.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Reopens: #2879
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>
