Previously it was marked as failing on macOS, but commit
ed3998b390 seems to have fixed that. yay!
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
The access and creation time tests create a file, gets the time in
seconds, then gets the time in microseconds and assumes that the
difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
This is the same fix as 289f8b, but that was just modification time.
Signed-off-by: Ross Burton <ross.burton@arm.com>
g_close() now is async-signal-safe, as long as we don't request a GError
and pass a valid file descriptor.
Update "gspawn.c" to drop its safe_close() function and use
g_close() instead.
g_close() does something useful. It is not trivial to get EINTR handling of
close() right, in a portable manner. g_close() abstracts this.
We should allow glib users to use the function even in async-signal-safe
contexts, at least if the user heeds the caveat about GError and take care
not to fail assertions.
Retry on EINTR is wrong on many OS, including Linux. See the comment
in g_close() why that is.
As we cannot use g_close() after fork, we had safe_close(). This had the
wrong retry loop on EINTR. Drop that.
This was especially problematic since commit 6f46294227 ('gspawn: Don’t
use g_close() in async-signal-safe context'). Before, safe_close() was
only called after fork, where there is only one thread and there is no
concern about a race.
This patch only exists for easier backporting of the bugfix. The code
will be reworked further next.
Fixes: 6f46294227 ('gspawn: Don’t use g_close() in async-signal-safe context')
In recent Clang we may get a build warning as per:
../gio/gtask.c: warning: implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1
[-Wsingle-bit-bitfield-constant-conversion]
This is because we use gboolean (and thus a signed type) for bit-fields.
Now, this is not an issue in practice for the way we're using them, but
still better to mute such compiler warns in the right way.
Freebsd doesn't always have /proc mounted, so relying on
/proc for the tests isn't ideal.
This commit changes the desktop-app-info tests to use
mkfifo instead of /proc/../fd/.. to relay terminal
arguments.
Might help with this error message I'm seeing in CI:
/tmp/bin-path-H1UQT1/gnome-terminal: cannot create /proc/38961/fd/6: No such file or directory
In case the XDG database is not initialized yet we may try to sniff a
0-length data, making our content-type routines to mark non-empty files
as `application/x-zerosize`.
This is wrong, so in case the sniff size is not set, let's just
try to read the default value. To avoid false-application/x-zerosize
results (that are not something we want as per legacy assumptions).
See: https://bugzilla.gnome.org/show_bug.cgi?id=755795
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2742
It causes the tests to fail, which suggests some latent FD handling bug
on macOS (but not other platforms).
Unfortunately I’m unable to debug that due to not having access to a
macOS machine, and it’s blocking CI for the rest of the project.
So disable it on macOS for now, until someone with access to a macOS
machine can take a look.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2785
They only indicate whether the value had to be modified to keep it
valid. That doesn’t matter when binding values.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1498116, #1498114
Return `G_VARIANT_PARSE_ERROR_RECURSION` from `g_variant_parse()` if a
typedecl is found within a text-form variant which would cause any part
of the variant to exceed the maximum allowed recursion/nesting depth.
This fixes an oversight when `G_VARIANT_MAX_RECURSION_DEPTH` was
implemented, which allowed typedecls to effectively multiply the size of
an array if `g_variant_parse()` was parsing a text-form variant without
a top-level concrete type specified.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2782
oss-fuzz#49462
At the moment, glib assumes that if /etc/localtime is a symlink,
that it's a symlink to zoneinfo file.
Toolbx containers add an extra layer of indirection though, making
it a symlink to a symlink to a zoneinfo file.
This commit deals with the problem, by performing additional checks
on /etc/localtime and ignoring it if those check fail, falling back
instead to reading /etc/timezone.
The usual use of G_DISABLE_CAST_CHECKS is to define it without giving it
a value. The value was never looked at until
f946e45a0c, where I decided it would be
cool to ignore it if defined to 0. But this broke the original usage, so
we need to revert that.
I thought it would be a good idea to look at the value in order to give
applications an off switch for the new behavior, so you could continue
to build optimized builds with cast checks enabled. We could still try
to find a way to do that in the future if desired, e.g. by introducing a
new G_ENABLE_CAST_CHECKS definition. But this doesn't seem especially
important. G_DISABLE_CAST_CHECKS is not documented anyway, so how we
handle cast checks is entirely up to GLib.
The previous text was technically correct, but not very clear what
happens with the ownership of the key/value if it was not returned.
Elaborate on the fact, that the key/value is never destroyed, even if
not requested by the user.
I intuitively expected the function to behave differently, that is, to
destroy the key/value if (and only if) it was not returned. That is,
when the function does not return a pointer, then it would destroy it.
That would seem more consistent to me, where ownership is either
transferred to the caller, or the resource destroyed during the steal.
On the other hand, the existing behaviors is:
- is consistent with g_hash_table_steal() and never destroys key/value.
- behaves the same, regardless whether the key/value was returned.
So the existing behavior may be better.
Just elaborate on that detail in the doc.
An application must keep track of the file descriptors that it
has. Closing an invalid, non-negative file descriptor is usually
a bug, because it indicates somebody messed up the tracking.
On a single threaded application it may be fine, but EBADF is always a bug
in a multi threaded application because another thread might race
reusing the bad file descriptor. With GDBus and other glib API, it is very
common that your application has multiple threads running and this is
in fact a bug.
The assertion failure does not necessarily indicate that the bug
is in the caller. It could have been another part of the application
that wrongly closed the file descriptor.
