Very often when we want to convert a string to number, we assume that
the string contains only a number. We have g_ascii_strto* family of
functions to do the conversion but they are awkward to use - one has
to check if errno is zero, end_ptr is not NULL and *end_ptr points to
the terminating nul and then do the bounds checking. Many projects
need this kind of functionality, so it gets reimplemented all the
time.
This commit adds some replacement functions that convert a string to a
signed or unsigned number that also follows the usual way of error
reporting - returning FALSE on failure and filling an error output
parameter.
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues. Fix this by:
-Doing what we did before on Python 2.x
-Open the file with encoding='utf-8' on Python 3.x
On 64 bit Android this is #defined to 0, which is considered an invalid
library handle in all other cases. RTLD_DEFAULT is only supposed to be
used with dlsym() it seems, and the usage here was just an
"optimization" before.
By dlopen'ing NULL, we get the same on all 64 bit Android variants and it
actually works instead of erroring out. On 32 bit Android, dlopen() of
NULL unfortunately usually gives us something useless that finds no
symbols whatsoever.
https://bugzilla.gnome.org/show_bug.cgi?id=776876
mnt_table_is_fs_mounted causes unwanted automount requests due to
canonicalization of source and target. It might be replaced by
mnt_table_find_source as per the documentation in order to prevent
the automounts, but it is redundant. All mtab entries should be already
mounted and thus mnt_table_is_fs_mounted result is always true (it
basically checks that the fs from mtab is in mtab). Let's remove
the check at all.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
libmnt_context is useless. It contains cache which is useful for searching,
but it isn't used in our case. Let's use mnt_context_parse_mtab instead
directly and the mtab processing will be faster.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
The test_stdio_wrappers() test will spuriously fail if the mkdir-test
directory already exists and is non-empty, which can happen if a
previous test run has failed and left a coredump file in the directory.
Tighten up the error checking around the pre-test rmdir() call to catch
this failure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782237
Use the new g_assert_{non,}null(), g_assert_cmpint(), g_assert_true(),
etc., to get more descriptive output when the tests fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782237
g_time_val_to_iso8601() has a limit to the future dates it can convert,
imposed by what gmtime() can fit in its year field. If gmtime() fails,
gracefully return NULL from g_time_val_to_iso8601() rather than trying
to dereference the NULL structure and crashing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782075
GDateTime does overflow checks to see if the timestamp being passed in
is too big to be represented. However, it only does those after
converting from a timestamp to an interval, which involves some
multiplications and additions — and hence can overflow, and cause the
later bounds check to erroneously succeed. This results in a non-NULL
GDateTime being returned which represents completely the wrong date.
Fix the overflow checks (do them earlier) and add some unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782089
Partially based on telepathy-glib’s tp_g_ptr_array_contains(), and a
patch by Xavier Claessens <xavier.claessens@collabora.co.uk>.
Test cases included.
https://bugzilla.gnome.org/show_bug.cgi?id=698064
The GNetworkMonitor docs were talking about one implementation,
omitting the others. While fixing that, add a bit about implementations
to the GProxyResolver docs too.
When we are inside a sandbox, we want to use the portal
implementation, since it is the only one that has a chance
of working.
This is safe to do, since the portal implementation will
just fail initialization when loaded outside a sandbox.
The flatpak-info file was moved to a different location a while
ago, we should read it from there instead of relying on the
compat symlink. One advantage is that this is a fixed, short
path, we don't have to construct one dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=781826
Looks like the author started typing one thing, then changed their mind
about how to phrase the sentence, and typed something else.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
And clarify that you must add a child watch or *not* use the
G_SPAWN_DO_NOT_REAP_CHILD flag, otherwise your child will become a
zombie on exit, and will not be reaped until the parent process exits.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Otherwise, we might end up returning TRUE from
g_app_info_launch_default_for_uri but with a set error parameter. This
will lead to confusing results depending on how the caller checks for
errors. Checking error != NULL indicats the call failed but checking the
return value indicates that it succeeded.
This way code that does not manually include the generated marshallers
header and wishes to build with `-Wmissing-prototypes` will not generate
a compiler warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781755
There are a few places where commit 18a33f72 replaced valid (nullable)
(optional) annotations with just (optional). That has a different
meaning.
(nullable) (optional) can only be applied to gpointer* parameters, and
means that both the gpointer* and returned gpointer can be NULL. i.e.
The caller can pass in NULL to ignore the return value; and the returned
value can be NULL.
(optional) can be applied to anything* parameters, and means that the
anything* can be NULL. i.e. The caller can pass in NULL to ignore the
return value. The return value cannot be NULL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some annotations I made while trying to debug bug #781847. They
introduce no behavioural changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reformatted the docs for G_VARIANT_TYPE_UINT64 to avoid having a
number in the beginning of the line, because apparently gtk-doc treats
that as a first element of the numbered list. The number being that
big probably makes gtk-doc to treat it as 1.
Fixed the g_variant_new_fixed_array documentation - it was partially
copy-pasted from the g_variant_get_fixed_array documentation.
The rest should be quite obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=781830
Temporarily increase the ref count of a GSource to 1 while calling its
finalize() callback, so that the finalize() implementation can call
GSource methods (like g_source_set_ready_time()) without causing
critical warnings. It’s safe to call those methods at this point, as the
source has been destroyed, but nothing has been freed.
This is an indirect way of fixing a race between GCancellable and
GCancellableSource, whereby the GCancellable::cancelled callback for the
GCancellableSource is not disconnected until the GCancellableSource’s
finalize() function is called. Previously, this meant there was a window
in which the GCancellableSource’s ref count was 0, but the ::cancelled
callback was still connected, and could legitimately be called as a
result of another thread calling g_cancellable_cancel() on the
GCancellable. The callback calls g_source_set_ready_time() on the
GSource, and there’s no thread-safe way of checking whether the GSource
has been destroyed. Instead, we have to change GSource so its ref count
is only decremented to 0 inside the locked section in
g_source_unref_internal() *after* the finalize() function has been
called, and hence after the GCancellable::cancelled callback has been
disconnected. The use of g_cancellable_disconnect() ensures that the
callback disconnection is thread safe.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781601
