The `g_content_type_guess_for_tree` function segfaults currently when
processing filenames that are not valid unicode strings. Let's use the
`g_filename_to_utf8` and `g_utf8_make_valid` functions before other
processing to prevent that.
Let's also add a test for it to avoid this in future.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
g_option_context_parse()/g_application_run()/g_test_init() for
convenience also call g_set_prgname(), when the prgname is unset at this
point. This was racy.
Fix the race by using an atomic compare-and-exchange and only reset the
value, if it is unset still.
g_set_application_name() guards against being reset, but it doesn't
remember whether it was set, it only checks whether g_application_name
was set to non-NULL. When allowing g_set_application_name(NULL) that leads
to odd behaviors, like:
g_set_application_name(NULL);
g_set_application_name("foo");
would not warn.
Disallow that and assert against a NULL application_name.
Note that application_name argument is also not marked as "(nullable)".
Now that libgirepository uses `GI_AVAILABLE_IN_*` macros, that’s what
controls symbol visibility. The `_` prefixes are redundant, and out of
keeping with the rest of GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Now that libgirepository is inside glib.git, it’s guaranteed access to
all the latest APIs, so there’s no need for version checks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
After bumping the major version number, we don’t need backwards
compatibility any more.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These are one-time allocations which are still reachable at the end of
the process. They cause warnings like this in valgrind:
```
==14408== 128 bytes in 1 blocks are definitely lost in loss record 1,287 of 1,403
==14408== at 0x4847A40: realloc (vg_replace_malloc.c:1649)
==14408== by 0x48CCD6E: g_realloc (gmem.c:201)
==14408== by 0x48F4CB1: g_string_expand (gstring.c:82)
==14408== by 0x48F4D59: g_string_sized_new (gstring.c:113)
==14408== by 0x48F4D91: g_string_new (gstring.c:134)
==14408== by 0x48A5805: g_build_path_va (gfileutils.c:1929)
==14408== by 0x48A62D1: g_build_filename_va (gfileutils.c:2222)
==14408== by 0x48A63FE: g_build_filename (gfileutils.c:2316)
==14408== by 0x491CD89: g_build_user_data_dir (gutils.c:1879)
==14408== by 0x491CDCF: g_get_user_data_dir (gutils.c:1920)
==14408== by 0x4B51E53: _g_content_type_set_mime_dirs_locked (gcontenttype.c:145)
==14408== by 0x4B51F33: g_content_type_set_mime_dirs (gcontenttype.c:194)
==14408== by 0x40C222: main (desktop-app-info.c:1880)
```
For example in https://gitlab.gnome.org/GNOME/glib/-/jobs/3278564
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When `--attributes` is specified and doesn’t include `standard::name` in
its list, `gio` would print a critical warning from the (mandatory) call
to `g_file_info_get_name()`.
Fix that by making the call to `g_file_info_get_name()` optional.
Add a unit test too.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3158
It gives nowhere near full coverage, but it’s something we can build on
in future.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3158
Helps: #2950
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.
Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If the help output is explicitly requested by the user, it’s
conventional for it to be printed to stdout rather than stderr.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Store their details in an array which can be iterated over instead.
This introduces no functional changes, just a cleanup which will allow
following commits to be neater.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Mention that ready time being equal to the current time means the source
will fire immediately.
Related to https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
If she socket is dispatched at exactly the previously set ready time,
it should already be considered to have timed out. This can easily
happen in practice when using a low resolution timer.
This fixes a test failure on GNU/Hurd, see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Instead of tracking a "(guint,GSource*)" tuple in the "context->sources"
dictionary, only track pointers to the "source_id".
With this we use the GHashTable as Set (g_hash_table_add()), which is
optimized and avoids storing a separate value array.
It's simple enough to do, because there are literally 5 references to
"context->sources". It's easy to review those usages and reason that the
handling is correct.
While at it, in g_main_context_find_source_by_id() move the check for
SOURCE_DESTROYED() inside the lock. It's not obvious that doing this
without a lock was correct in every case. But doing the check with
a lock should be fast enough to not worry about whether it's absolutely
necessary.
We have g_int_hash()/g_int_equal(), which in practice might also work
with with pointers to unsigned integers. However, according to strict
interpretation of C, I think it is not valid to conflate the two.
Even if it were valid in all cases that we want to support, we should
still have separate g_uint_{hash,equal} functions (e.g. by just #define
them to their underlying g_int_{hash,equal} implementations).
Add instead internal hash/equal functions for guint.
