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>
GCC >= 4.7 and clang >= 12 don't need it. It should be left to the user
to decide what ABI convention should be used, and it creates some issues
with some tools to have this flag in cflags.
We leave the flag for now, but print a warning at compile time so people
get a chance to change their build system before we drop it from glib.pc
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The tooling won’t pick them up unless they’re directly above the gettext
calls.
Spotted by Piotr Drąg in
ec03755355 (note_1808152).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The test case will fail with the
g_assert_false (g_subprocess_get_successful (proc));
assert failing. Without the fix, it'll hit sometimes, but rather
unreliably. When running `meson test --repeat 100`, it'll reproduce
anywhere between the first or much later, but mostly before the 20th
iteration on my system.
Helps: #3071
We might repeatedly get si_pid == 0 for a child that hasn't exited,
meaning we won't get a correct exit status. This seems to happen when
the glib application tracks a ptrace():ed child process; the correct
exit status of the process using e.g. a BPF program, where one can
observe that glib appears to get it wrong.
Fixes: #3071
While it's only called one time, this is something that can only happen
during the function call, so it's more correct to mark it as call scope,
so that bindings don't have to wait for the callback invocation to
cleanup the data.
As per commit 5d738ddc some callbacks are not nullable anymore even
though they should be.
This breaks the introspection as some arguments won't be considered
nullable anymore.
You can notice this in https://gitlab.gnome.org/3v1n0/gjs/-/pipelines/558839
where some some tests are running against stable g-i version and others
(the failing ones) against the devel one.
Currently, when adding new elements to GTree we blindly increment the node
counter, which is only of guint size (so 32-bit even on 64-bit Unix
platforms).
This is even more problematic because the only way to check whether
particular GTree is empty is to check whether its node count is zero.
This will obviously give wrong answer if this counter overflows.
Let's fix this by adding an appropriate check when adding a new node.
For the recently added g_tree_{insert,replace}_node () API we can simply
return NULL in such case.
However, the older g_tree_{insert,replace} () API doesn't have any ability
to return an error so for them we follow the example of
g_ptr_array_extend () and g_ptr_array_set_size () by calling g_error ()
when this happens.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
g_tree_nnodes () is returning a signed integer type (gint), however the
tree node counter value type is really an unsigned integer (guint).
This means that the returned size will be negative if the container holds
more than G_MAXINT elements.
Add a note to this function that its return value can be cast back to
guint in order to support its full range of values.
This will also make sure that we take this into account in future Glib
versions.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
It's not safe to use setlocale() to mutate the locale in a threaded
program. Lots of other tests still do this, and I'm not putting in the
effort to fix them comprehensively in the absense of actual failures on
CI, but I figured it'd be good to fix the tests that I was touching.
This definitely does not do anything on Linux. I bet it's not needed on
other platforms, either. It's unsafe and may crash; there is no safe way
to mutate the environment in threaded programs.
This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
It's supposed to be possible to translate settings values using LC_TIME
rather than LC_MESSAGES to determine which translation to use, but
Sebastian Keller noticed that it's not working properly. I've
implemented his proposed solution, which is to actually temporarily
change LC_MESSAGES to match LC_TIME for just as long as necessary to
force gettext to use the desired message catalog.
Fixes#2575
Fix typo in gio/gappinfo (duplicated word)
Fix typo in gio/gtlsdatabase.c (duplicated word)
Fix typo in gio/gapplication.c (duplicated word, previous words rearranged to improve readability)
Fix typo in glib/tests/gvariant.c (duplicated word)
Fix typo in glib/win_iconv.c (duplicated word)
Fix typo in gio/gschema.dtd (meaning, missing letter)
Fix typo in gio/gdbusintrospection.c (duplicated word)
Fix typo in gio/gdbusintrospection.c (duplicated word).
