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.
For completeness. There probably won't be any, but the XDG base directory
specification is most useful if it's consistently followed everywhere,
and the specification says to look in XDG_DATA_HOME before XDG_DATA_DIRS.
Signed-off-by: Simon McVittie <smcv@debian.org>
The Python code historically always searched DATADIR/gir-1.0 (always)
and /usr/share/gir-1.0 (only on Unix); since the previous commit, they
are searched after the GIR_DIR. Do the same here, to make the C and
Python search paths match up.
With the default gir_dir_prefix, searching both GIR_DIR and
DATADIR/gir-1.0 is redundant. However, if gir_dir_prefix is changed to
something else, for example -Dgir_dir_prefix=lib64, always searching
DATADIR/gir-1.0 provides backwards compatibility with pre-existing GIR
that might already be stored in DATADIR/gir-1.0.
Resolves: #455 (in conjunction with previous commit)
Helps: #323
Signed-off-by: Simon McVittie <smcv@debian.org>
This is searched after any command-line includes paths, but before the
XDG_DATA_DIRS or any built-in paths. For example, if
libraries are installed in /opt/gnome and GObject-Introspection was
configured with -Dgir_dir_prefix=lib64, you could set either
GI_GIR_PATH=/opt/gnome/lib64/gir-1.0 or
XDG_DATA_DIRS=/opt/gnome/lib64:/opt/gnome/share:${XDG_DATA_DIRS}.
Use this to communicate the ../gir directory to giscanner instead
of modifying Python's builtins.
Helps: #323, #455
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
