On 32 bit systems 'long' value will overflow in 2038 and become negative.
As it is used to index into letters array, and % operation preserves signs,
data corruption will then occur.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
The point of to be able to call localtime()/localtime_r() from another
place inside glib (without reimplementing the #ifdef).
- also handles failures from localtime_r(). It is documented that it
might fail, so detect the failure.
- in case of failures of localtime(), still initialize the GDate.
Previously, we may error out with a g_critical() assertion before.
However, now that failures from localtime_r() are also caught, I think
we should make an effort to initialize the GDate to something. It
either way it not supposed to happen.
Print the PID, the errno and the pidfd in case of an unexpected failure
in g_child_watch_dispatch().
This is always(?) caused by a bug in the user application. Also hint to
g_child_watch_source_new() documentation for possible causes.
Also use G_PID_FORMAT for printing GPid values.
Prompted by #3071, this clarifies that `g_test_trap_subprocess()` uses
`g_child_watch_source_new()` internally, so it will not work if any of
the preconditions for using that API are not met. In particular, if
`SIGCHLD` is ignored, things will break.
This documentation is not meant to be an API guarantee which constrains
the implementation of `g_test_trap_subprocess()` in future, just a tip
to people currently using the API.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3071
This is one step towards rectifying the mistake of using `FD_CLOEXEC` in
the first place. Eventually we may deprecate support for `FD_CLOEXEC`,
as the `O_*` flags better match the underlying `pipe()` API.
See discussion on
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3459#note_1779264
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Since 5c65437d "glib-unix: Add O_NONBLOCK support to g_unix_open_pipe()"
we have been using O_NONBLOCK unconditionally, so we might as well drop
the fallback here as well. This commit should be reverted if someone
reports a significant/supported platform that genuinely doesn't have
O_NONBLOCK.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Since 5c65437d "glib-unix: Add O_NONBLOCK support to g_unix_open_pipe()"
we have effectively been assuming that these two flags are
distinguishable. If that's an assumption we want to make, we should make
it a static assertion, so that GLib will fail to compile on platforms
where it isn't true.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previous default used was 32KiB (the library default) which caused some
complex patterns to fail, see #2824. The memory will not be allocated
unless used.
There is no point to enable jit in g_regex_new, since JIT will be only
used when we do a first match, and at that point
enable_jit_with_match_options will be called again already and will
update the options set in g_regex_new. Instead just run it at first
match for the first time, to the same end result.
Follow-up to e234a4496e to remove the old
`only: main`, which was overriding the changes from that commit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Since commit b9b7816e5a, the `pages` job
will still try to be run on `main` after an MR is merged, but will fail
because it depends on `coverage` and `style-check-advisory`, which are
no longer run on `main` after a merge.
See https://gitlab.gnome.org/GNOME/glib/-/pipelines/560680 for an
example failure.
Instead, make the `pages` job only run at the end of a scheduled CI run.
Its dependent jobs will have run then. This means that the ‘canonical’
code coverage report at
https://gnome.pages.gitlab.gnome.org/glib/coverage/ will be updated once
a week, rather than after every merge into `main`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Add test cases that result in lookup of the port via
getservbyname().
As the result depends on "/etc/services", it's not reliably the same on
every system. It requires a workaround.
Commit cf55c31170 added a new test which
uses `ptrace()` to check some `GSubprocess` behaviour. FreeBSD uses
different symbol names for ptrace symbols, and we haven’t tested whether
the test works (and reproduces the failure) on FreeBSD, so skip the test
for now.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
