Move the shebang line from the full Python path of the build
machine to the first Python on the path during runtime. Set
the shebang in the main meson.build file so that it can be
overridden in one place if needed.
Fixes: #3331
As gettext does:
* if C locale is used to set a value, set the untranslated value, i.e.
key=value and not key[C]=value;
* if C locale is used to get a value, return the untranslated value,
i.e. not the value from key[C]=value, if it ever exists, and do not
consider C as an undefined locale otherwise.
Fixes: #3578
It wasn’t clear what the fallback behaviour of IPv4 vs IPv6 was, or that
the same port was used for both.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It wasn’t clear what the fallback behaviour of IPv4 vs IPv6 was, or that
the same port was used for both.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In add_any_inet_port() for the case where we successfully listen()ed
on IPv6, but failed to listen on IPv4, we would erroneously unref the
IPv6 socket which we just gave away ownership of by adding it to
priv->sockets.
However, given that we have a successful IPv6 socket, we shouldn’t
report it as an error if the IPv4 listen() fails. While this code tries
quite hard to return both sockets, returning only one seems to be the
best we can do in this situation.
This issue was observed in an Android 4.4 ARM emulator. It’s possible
the emulator deferred the bind() on the host until the listen() on the
client.
Based on a patch by Ole André Vadla Ravnås <oleavr@gmail.com>.
https://gitlab.gnome.org/GNOME/glib/issues/1250
These refcount changes cannot possibly fix any race condition because
there is no guarantee that the g_source_ref() will be called in this
thread before any g_source_unref() that might happen on another thread.
We would have to take the ref sooner for it to be effective.
It's also not clear why we take a ref at all, since the source is
already being disposed and there's no explanation of why we should
resurrect it here. It can't be finialized until the call to dispose is
finished, so it's unclear what we are guarding against.
I'm not sure about the correctness of this code and make no promises
that there are no bugs here, but I think this change shouldn't make
anything worse.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4387#note_2269324
This adds a test to increase the code coverage of `nameprep()` in
`ghostutils.c`. It was previously missing coverage of the second
`tolower()` operation. The new test triggers this by using a Unicode
codepoint which cannot be converted to lowercase itself, but which
normalises (NFKC) to uppercase characters which can — a Unicode Roman
numeral.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It uses a `GArray` to build up the output, and the size of that is
limited to a `guint`, so add an assertion to make sure the code never
requests anything bigger.
Fixes a `-Wshorten-64-to-32` warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
Rename the `tmp` variable to `name_owned` to make its purpose clearer,
and more consistently assign to both it and `name` and `len` (which is
the length of `name`) every time any of them are modified.
This should make the function `const`-correct without the need for
casts, and introduce no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than `gint`, which can overflow for long strings, although such
strings would probably have hit hostname length limits already.
This fixes a `-Wshorten-64-to-32` warning.
I looked at changing from `gssize` to `size_t` and handling the `len <
0` case with an explicit early call to `strlen()`, but it didn’t make
things simpler, as the code in `nameprep()` keeps changing the length of
the string as it processes it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
When parsing command line options, use `size_t` to hold string lengths.
This introduces no functional changes (any strings long enough to fit in
`size_t` but not in `int` will probably hit command line length limits),
but it does fix a `-Wshorten-64-to-32` warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
This introduces no functional changes, it just splits the declaration of
`j` into three smaller-scoped declarations of the same type. This will
make the following commit clearer.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
The code uses `strtol()` to parse an integer from a string, then
correctly verifies its range, then it did an implicit cast to `int` to
return the parsed integer. This causes a spurious `-Wshorten-64-to-32`
warning, so add an explicit cast to make the code’s intention clear.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
This moves all the string length handling in this part of `goption.c` to
use `size_t`. However, we need to assert that the string length is
at most `G_MAXINT` later on, as the length is passed to `printf()` to
add indentation, and it only accepts `int` for that kind of placeholder.
This introduces no functional changes, but does fix some
`-Wshorten-64-to-32` warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
When parsing the pattern in `g_pattern_spec_new()`, the offsets of
wildcards and jokers were stored in a `gint`. This could overflow with
exceptionally long patterns.
Split the sign out into a separate boolean for `hw_pos` and `hj_pos`
(it’s not necessary for `tw_pos` or `tj_pos` because their sign was
never queried), and use `size_t` to correctly store string offsets.
Fixes a `-Wshorten-64-to-32` warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
The seed is explicitly a `guint32`, so an implicit cast was already
happening. We don’t actually care if there’s a loss of precision here,
as it’s a pseudo-random seed value rather than an ordinal number, so add
an explicit cast to silence the warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
This fixes a `-Wshorten-64-to-32` warning, but there’s no underlying bug
here, as the maximum requested read size is 4 bytes anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
There’s already a documented explicit cast here, so let’s add the
explicit cast in C to match that. Fixes a `-Wshorten-64-to-32` warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
Link to the toolchain requirements, which are kept up to date, rather
than duplicating them across multiple documents.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will warn if GLib is configured with a toolchain which doesn’t
support C11. We currently require C99. If nobody complains (as directed
by this warning) we will start to require C11 in the next unstable
release series (2.85).
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3574#note_1859924
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Prevent to access to a disposed gsource in the GCancellable cancelled
signal callback.
Due to the fact that the signal is called in the same thread in which
the cancellable get cancelled, we may receive the callback just after
the GSource has been disposed or during its disposal.
To prevent this, let's pass to the signal a pointer to the source itself
and nullify atomically the first time we're calling a callback or
disposing it.
In case the dispose function wins the race, then the callback will just
do nothing, while the disposal will continue as expected.
In case the callback wins the race, during the concurrent disposal we'll
just wait for the callback to be completed, before returning the disposal
itself that will likely lead to freeing the GSource.
Closes: #3448
It finally happened: someone managed to keep a process alive long
enough, and using a single `GDBusConnection`, to overflow the
`last_serial` counter in the connection and send an invalid message with
serial of zero (which is disallowed by the D-Bus specification).
Avoid that happening in future by skipping serials of zero on overflow,
and wrapping straight back around to 1.
This looks a little more confusing than it is, because `last_serial` is
pre-incremented on use, so to skip zero, we explicitly set it to zero.
This is exactly what happens when the `GDBusConnection` is initialised
anyway.
I can’t think of a way to add a unit test for this — there is no way to
affect the value of `last_serial` except by sending messages (each one
increments it), and in order to get it to overflow by sending messages
at 1kHz, the test would have to run for 49 days.
Instead, I tested this manually by temporarily modifying
`GDBusConnection` to initialise `last_serial` to `G_MAXUINT32 - 3`, then
checked that the unit tests all still passed, and that the overflow code
was being executed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3592
The registry backend uses a thread to monitor
registry changes and send notifications.
The state of this thread and structures used
for communicating with it are kept in the watch
variable.
The subscribe and unsubscribe functions might be
concurrently called from multiple threads and
need to communicate with the monitoring thread.
For this reason we need to synchronize the access
to the watch variable.
