You may not always know which schemes are available.
The library should not bail out, but only show
an informal message. It's the responsibility of
the application to deal with invalid URI schemes.
The test brings a Finder window to the front. It's not ideal,
but I have no better idea at the moment. It would be cool if we
can make the test case register itself as handler for a particular
uri scheme, but I have no idea how to do that.
GHashTable optimizes for the "set" case, where key and value are the same.
See g_hash_table_add().
A user cannot see from outside, whether a GHashTable internally is a set
and shares the keys and values array. Adding one key/value pair with
differing key and value, will expand the GHashTable.
In all other cases, the GHashTable API hides this implementation detail
correctly. Except with g_hash_table_steal_extended(), when stealing both the
key and the value.
Fix that. This bug fix is obviously a change in behavior. In practice,
it's unlikely that somebody would notice, because GHashTable contains
opaque pointers and the user must know what the keys/values are and
be aware of their ownership semantics when stealing them. That means,
the change in behavior only affects instances that are internally a set,
of what the user most likely is aware and fills the table with
g_hash_table_add(). Such a user would not steal both the key and
values at the same time. Even if they do, then previously stealing the
value was pointless and would not give them what they wanted. It would
not have meaningfully worked, and since nobody reported a bug about this
yet, it's unlikely somebody noticed.
The more problematic case when the user exhibits the bug is when the
dictionary is unexpected a set internally. Imagine a mapping from numbers
to numbers (e.g. a permutation). If "unexpectedly" the dictionary contains
the identity permutation, steal-extended gives always NULL for the target
number.
The example is far fetched. In practice, it's unlikely that somebody is
gonna notice either way. That is not an argument for fixing anything.
The argument for fixing this, is that the bug breaks the illusion that
the set is only an internal optimization. That is ugly and inconsistent.
Some g++ versions issue an unused-result warning for the g_string_free() macro:
error: ignoring return value of 'gchar* g_string_free_and_steal(GString*)',
declared with attribute warn_unused_result [-Werror=unused-result]
g_string_free(s, TRUE);
This occurs with gcc 6.x / 7.1 / 7.2, and it is fixed in gcc 7.3.
I answered a question on irc about withdrawing notifications, and
when I handed out a link to the GApplication docs, I noticed we
don't have this function name linkified. Fix that.
This fixes the annoations for g_mapped_file_get_contents() which looks
like it might transfer ownership (due to being a char*) but does not as
we're pointing into the mmap() region.
The issue of meson 60 have been resolved for some time now, so we can
just use newer TAP syntax safely.
Revert "gtestutils: Use TAP 13 comments syntax for subtests"
This reverts commit e8725407bcd35c1fa8fed92250edf080d5542b3c.
Closes: #2885
Now that we've switched to `gi-docgen`, let's make sure our docs are
getting updated. This commit fixes most of the previous gtk-doc
references so that they now follow gi-docgen syntax.
Some exceptions are functions or types that are referenced, but are
generated by a higher level layer like `Gio`, `GObject` or `Gtk`.
On Wayland the activation token returned by
`g_app_launch_context_get_startup_notify_id()` doesn't depend on the
`GAppInfo`. The token is only used to hand over focus to the
application that is launched. In some cases it's not even possible to know
what application will actually be used to open the files. For example
when using portals within a sandbox. Therefore, allow providing no
`GAppInfo`.
This also makes clear in the docs that the `files` argument can be `NULL`.
We want to add the support for the activation token, to get it we use
`g_app_launch_context_get_startup_notify_id` which takes a list of
files, so that we don't have to create a GFile twice simply change the
signature of the functions. Fortunately this isn't a public API.
Some callers of `g_ascii_strtoull()` and similar functions assume that
they can use this pattern, similar to what they might do for
Standard C `strtoull()`:
errno = 0;
result = g_ascii_strtoull (nptr, endptr, base);
saved_errno = errno;
if (saved_errno != 0)
g_printerr ("error parsing %s\n", nptr);
This is based on the fact that it is non-trivial to tell whether
`strtoull()` and related functions succeeded (in which case the value
of `errno` is unspecified) or failed (in which case `errno` is valid).
For example, POSIX `strtoul(3)` suggests this pattern:
> Since 0, `ULONG_MAX`, and `ULLONG_MAX` are returned on error and are
> also valid returns on success, an application wishing to check for
> error situations should set `errno` to 0, then call `strtoul()` or
> `strtoull()`, then check `errno`.
However, `g_ascii_strtoull()` does not *only* call a function resembling
`strtoull()` (`strtoull_l()` or its reimplementation
`g_parse_long_long()`): it also calls `get_C_locale()`, which wraps
`newlocale()`. Even if `newlocale()` succeeds (which in practice we
expect and assume that it will), it is valid for it to clobber `errno`.
For example, it might attempt to open a file that only conditionally
exists, which would leave `errno` set to `ENOENT`.
This is difficult to reproduce in practice: I encountered what I
believe to be this bug when compiling GLib-based software for i386 in a
Debian 12 derivative via an Open Build Service instance, but I could
not reproduce the bug in a similar chroot environment locally, and I
also could not reproduce the bug when compiling for x86_64 or for a
Debian 10, 11 or 13 derivative on the same Open Build Service instance.
It also cannot be reproduced via the GTest framework, because
`g_test_init()` indirectly calls `g_ascii_strtoull()`, resulting in
the call to `newlocale()` already having happened by the time we enter
test code.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3418
Signed-off-by: Simon McVittie <smcv@collabora.com>
