| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Several small fixes to the build files.
Lots of tests have also been added, and glib tests pass now.
|
|
|
|
| |
https://mail.gnome.org/archives/gtk-devel-list/2013-August/msg00001.html
|
|
|
|
|
|
|
|
|
|
|
|
| |
g_dbus_connection_call_internal() accesses the user data it passes to
g_dbus_connection_send_message_with_reply() after the call. That data
might be freed already in the case that the callback is called
immediately.
Fix this by removing the 'serial' field from the user data altogether
and fetch the serial from the message in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=748263
|
| |
|
| |
|
|
|
|
|
|
| |
The tool that extracts the translatable strings to .po files does not
cope with the G_GUINTX_FORMAT macros, so we preformat the numbers to
strings and use the strings in the translatable error messages.
|
| |
|
|
|
|
| |
Something I spotted by accident with git log.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
64 bit
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
|
|
|
|
|
|
|
| |
They are no #defines on Android but enum values, and on 64 bit Android
they have different values than what we would otherwise fall-back to.
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
|
|
|
|
| |
This reverts commit 8446ee8c2039f233c084f0321f52f664941e4186.
|
|
|
|
| |
So that early adopters of new API have a version number to target.
|
|
|
|
|
|
|
| |
datetime->tz can never be NULL, so this pointer check is unnecessary and
confusing, and messes up static analysis.
https://bugzilla.gnome.org/show_bug.cgi?id=732000
|
|
|
|
|
|
|
|
| |
Instead, gperf should be used for that kind of thing.
Inspired by http://stackoverflow.com/q/42372382/2931197.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
| |
It should be 2^64-1, not just 2^64.
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Igor says: Thith code did not path the compilation check.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
It should be passed a mime type not a content type.
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=781755
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=781755
|
|
|
|
|
|
|
|
|
|
| |
The convention for arguments taking a value is:
--argument=VALUE
with the `VALUE` in caps.
https://bugzilla.gnome.org/show_bug.cgi?id=781755
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=777030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Add missing function, copying from gcontenttype-win32.c per Patrick
Griffis (Comment #55 of bug report)
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
|
|
| |
Verify presence of new interface.
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
|
|
| |
Correct error domain is G_IO_ERROR.
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
|
|
| |
This is the only way they are exposed on Unix so we need to handle it
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=734946
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780300
|
| |
|