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 `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.
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>
Change originally by Piotr in !3257, but the CI has problems with
his name in the author field. Since this change is blocking a release,
I have decided to merge it under my name instead, so that it lands sooner.
In parallel, we are trying to figure out what is broken with the CI so
this does not happen again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
