Otherwise clang would complain:
../glib/tests/strfuncs.c:2603:32: warning: result of comparison
against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
g_assert_true ((gpointer)str != (gpointer)"");
^ ~~~~~~~~~~~~
../glib/gtestutils.h:187:59: note: expanded from macro 'g_assert_true'
if G_LIKELY (expr) ; else \
^~~~
../glib/gmacros.h:1186:59: note: expanded from macro 'G_LIKELY'
#define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
^~~~
../glib/gmacros.h:1180:8: note: expanded from macro '_G_BOOLEAN_EXPR'
if (expr)
It’s entirely possible that `g_file_read_link()` will return a relative
path. Mention that in the documentation, and include a short example of
how to make the path absolute for further computation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The changes in 6265b2e6f7 to reject weird
`/etc/localtime` configurations where `/etc/localtime` links to another
symlink did not consider the case where the target of `/etc/localtime`
is a *relative* path. They only considered the case where the target is
absolute.
Relative paths are permissible in all symlinks. On my Fedora 36 system,
`/etc/localtime`’s target is `../usr/share/zoneinfo/Europe/London`.
Fix the check for toolbx by resolving relative paths before calling
`g_lstat()` on them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Standard C specifically does not guarantee this, and it's untrue on
CHERI architectures (which have 128-bit pointers into a 64-bit
address space, with the remaining bits used for a capability-like
mechanism).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Dereferencing a pointer to a 64-bit object as though it was a 32-bit
object is the same as taking the least significant 32 bits on a
little-endian machine, but on a big-endian machine it is the same as
taking the *most* significant 32 bits, which would result in these hash
functions always hashing to zero. The /hash/int64/collisions and
/hash/double/collisions test-cases in glib/tests/hash.c detect this
and fail.
Instead, fetch the whole 64-bit quantity and do the bit-manipulation
to xor the more significant half with the less significant half in an
architecture-neutral way.
Fixes: dd1f4f70 "Optimize g_double_hash implementation"
Fixes: c1af4b2b "Optional optimization for `g_int64_hash`"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2787
Signed-off-by: Simon McVittie <smcv@collabora.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')
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
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 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.
Otherwise the test will fail when run in a non-English locale.
Fix suggested by Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2754
* Add a test to check that smaller string than prefix/suffix are
handled in g_str_has_*() functions.
* Add a tests on macro prefixed function and ensure that function
itselves are tested as well.
Compilers can emit optimized code for str|strn|mem)cmp(str,"literal")
at compile-time. This commit use the preprocessor to introduce this
kind of optimization for the functions g_str_has_prefix() and
g_str_has_suffix().
Original work by Ben @bdejean
Closes issue #24
There is no guarantee that the thread pool will reach its limit afaict,
it depends how the system schedule the various threads. This fixes
random test failure on win32.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
GBookmarkFile has everything for being introspectable, but it lacks a
GType, because it can't be copied. So provide a copy function that
deeply copies all the bookmark structures.
Add tests for this.
In some bookmarks that we load the modified value may be not set, while
this may lead to a load error, we still can dump such file and this
would fail as we try to get a string from an invalid time.
Avoid this, because it would also lead to not writing a valid count
value, given that we'd pass NULL to g_strconcat too early.
This is like our other suite of g_set_*() based APIs to simplify and
improve correctness of setters for fields, properties, and more.
This implementation specifically handles setting string values that may
point to an offset within the current string by copying before free.
strcmp() is used directly (as opposed to g_strcmp0() due to it being in
gtestutils.h as well as to increase the chance that the compiler will
hoist the implementation.
Fixes#2747
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
Not that we ever expect it to fail. This is basically just to silence a
compiler warning with `-Werror=unused-result`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2758
Instead of going through the normal error logging code, which does
further allocations and will potentially call back into `g_vasprintf()`
and create an infinite loop, just `fputs()` an error message and abort.
If we’re getting `ENOMEM` the process is doomed anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2753
Otherwise, the build will fail when the toolchain is static-only, even
with -Ddefault_library=static. I talked to a Meson developer in their
IRC channel, who told me that the correct fix was to ensure that
shared_library is only used if default_library != static.
g_str_equal() is a nicer API than strcmp()==0, and less error prone.
However, forcing a function call prevents compiler from doing
optimizations. In the case it is not used as callback to GHashTable,
provide a macro that calls strcmp directly. This also has the side
effect that it forces arguments to be `const char *` instead of
`gconstpointer` in the case it is not used as callback, which adds type
safety.
Fixes: #2775
The flag is still ignored but this way we properly deprecate
at compile time without raising an unexpected criticals at runtime:
g_regex_new: assertion '(compile_options & ~G_REGEX_COMPILE_MASK) == 0' failed
and then failing to create the regex completely.
Fixes 8d5a44dc8 ("replace pcre1 with pcre2")
Previously it was wrongly assuming that a NUL-termianted string is
passed and the whole string should be written out.
Also document this bug in the documentation of g_log_structured() to
avoid surprises when using older GLib versions.
In case we got a compilation or match error we should try to provide
some useful error message, if possible, before returning a quite obscure
"internal error" or "unknown error" string.
So rely on PCRE2 strings even if they're not translated they can provide
better information than the ones we're currently giving.
Related to: https://gitlab.gnome.org/GNOME/glib/-/issues/2691
Related to: https://gitlab.gnome.org/GNOME/glib/-/issues/2760
- Insert missing word "from".
- Remove space between function name and "()" so syntax highlighting
can recognise it as a function.
- Avoid "you"/"your" when discussing the reentrancy issues of regular
UNIX signal handlers, because it gives the false impression that
these issues are applicable to g_unix_signal_source_new().
Unrelated:
- Fix missing space in documentation of g_signal_new_class_handler().
There are a few blocks in Unicode (mainly ideographs)
which default to wide. These blocks are defined in the
header comment of EastAsianWidth.txt.
We have some tests which check that unassigned codepoints
in those blocks get reported as wide, so make sure we handle
this correctly.
When compiling with C++ in MSCV, it defines the __cplusplus macro, but
that's set to an old value and it doesn't represent the current c++
standard version (unless when explicitly requested via `/Zc:__cplusplus`).
So, to enable modern features we should rely on `_MSC_LANG` instead,
which represent the value we care about.
The fix in ad23894c15 only works for
__cplusplus >= 201103L, but older C++ standards are not always less strict,
and still fail to compile the g_atomic_int_compare_and_exchange() and
g_atomic_pointer_compare_and_exchange() macros.
Apply that fix to all C++ standard versions.
Even if this implies using functions that have been added as part of
C++11 specification, this is safe because we wouldn't ever try to use the
`__atomic_...()` APIs if `__ATOMIC_SEQ_CST` is not defined, and that's part
of the very same API.
These functions may be defined as macros with different behaviors in
different c++ versions (as they rely on glib_typeof), so let's ensure
they work and compile everywhere.
When using an older C++ versions, the glib_typeof() macro is never
defined, as the C++ definition depends on __cplusplus >= 201103L, while the C
definition, which would work, depends on !defined(__cplusplus).
Allow old C++ versions to use the C macro definition for glib_typeof().
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
Though unlikely to happen, it may happen that newly created file
descriptor take the value 0 (stdin), 1 (stdout) or 2 (stderr) if one
of the standard ones have been dismissed in between. So, it may
confuse the program if it is unaware of this change.
The point of this patch is to avoid a reasign of standard file
descriptors on newly created ones.
Closes issue #16
Those tools are not needed at runtime for typical applications,
distributions typically package them separately.
This makes `meson install --tag runtime` skip installation of those
tools. Omitting `--tag` argument will still install them, as well as
with `--tag bin,bin-devel`.
See https://mesonbuild.com/Installing.html#installation-tags.
Do not store jit status for regex unless during initial compilation.
After that, decide whether to use it depending on matching options.
In fact there are some matching options that are incompatible with JIT,
as the PCRE2 docs states:
Setting PCRE2_ANCHORED or PCRE2_ENDANCHORED at match time is not
supported by the just-in-time (JIT) compiler. If it is set, JIT
matching is disabled and the interpretive code in pcre2_match() is
run. Apart from PCRE2_NO_JIT (obviously), the remaining options are
supported for JIT matching.
Fixes: GNOME/gtksourceview#283
There's no much point of pre-allocating offsets given that we're doing
this when needed if only have matches to store.
So let's just allocate the spaces for the dummy offset we depend on,
while allocate the others on demand.
While the ovector count would include all the allocated space, we only
care about the actual match values, so avoid wasting allocations and
just use the ones we need to hold the offsets.
In case PCRE2 returns an empty match
This can be easily tested by initializing the initial match data to a
value that is less than the expected match values (e.g. by calling
pcre2_match_data_create (1, NULL)), but we can't do it in our tests
without bigger changes.
We're using int for every size value while PCRE uses uint_32t or
PCRE2_SIZE (size_t in most platforms), let's use the same types to avoid
using different signs.
In case recalc_match_offsets() failed we were just returning, but in
such case, per the documentation we should still set the match_info (if
provided) and free the pcre2 code instance.
So let's just break the loop we're in it, as if we we've no matches set.
This also avoids re-allocating the offsets array and potentially
accessing to unset data.
In case we're getting NO-MATCH "errors", we were still recomputing the
match offsets and taking decisions based on that, that might lead to
undefined behavior.
Avoid this by just returning early a FALSE result (but with no error) in
case there's no result to proceed on.
Fixes: #2741
As per the PCRE2 port we still used to try to map the old GRegex flags
(PCRE1 based) with the new PCRE2 ones, but doing that we were also
mixing flags with enums, leading to unexpected behaviors when trying to
get new line and BSR options out of bigger flags arrays.
So, avoid doing any mapping and store the values as native PCRE2 flags
internally and converting them back only when requested.
This fixes some regressions on newline handling.
Fixes: #2729Fixes: #2688Fixes: GNOME/gtksourceview#278
For all the memory allocator APIS, document
that they terminate the program on failure.
This was so far only mentioned in the long description,
and in the docs for g_try_malloc(). And with gi-docgen
style docs, the long description is going away.
A file-descriptor was created with the introduction of pidfd_getfd() but
nothing is closing it when the source finalizes. The GChildWatchSource is
the creator and consumer of this FD and therefore responsible for closing
it on finalization.
The pidfd leak was introduced in !2408.
This fixes issues with Builder where anon_inode:[pidfd] exhaust the
available FD limit for the process.
Fixes#2708
man pcre2_pattern_info says that the 3rd argument must
point to uint32_t variable (except for some 2nd argument value),
so correctly use it. Especially using wrong size can cause
unexpected result on big endian.
closes: #2699
The prefix for GMarkupParseFlags enumeration members is G_MARKUP; this
means that G_MARKUP_PARSE_FLAGS_NONE gets split into
GLib.MarkupParseFlags.PARSE_FLAGS_NONE by the introspection scanner.
The `/*< nick=none >*/` trigraph attribute is a glib-mkenum thing, and
does not affect the introspection scanner; it would also only affect the
GEnumValue nickname, which is not used by language bindings to resolve
the name of the enumeration member. Plus, GMarkupParseFlags does not
have a corresponding GType anyway.
I want to use this in gio-launch-desktop, but gio-launch-desktop
doesn't depend on GLib, so I can't just call g_log_writer_is_journald().
Signed-off-by: Simon McVittie <smcv@collabora.com>
When run as an installed-test, assert-msg-test generally won't be in
the PATH, but it will be in the same directory as the installed copy
of this script, so we can find it that way.
This fixes an installed-tests failure in Debian's autopkgtest
environment.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In case JIT is not available in pcre2 we printed warning about it. This
warning broke tests on systems which don't have JIT support in pcre2
(e.g. macos).
Since we ported gregex to pcre2, the JIT compiler is now available to be
used. Let's undeprecate G_REGEX_OPTIMIZE flag to control whether the JIT
compilation is requested, since using JIT is itself an optimization.
See [1] for details on its implementation in pcre2.
[1] http://pcre.org/current/doc/html/pcre2jit.htmlFixes: #566
