This can easily happen if the owner of the remote object vanishes. Of
course, when that happens, user code is already notified (by e.g. the
notify::g-name-owner signal) so it can avoid using the proxy but
requiring that is a bit harsh. IOW, before this patch this critical
error was printed
GLib-GIO-CRITICAL **: g_dbus_gvariant_to_gvalue: assertion `value != NULL' failed
when that happened. With this patch, we just avoid setting the GValue
so the user will get the default value for its type instead. So, for
example, if the user code is getting a GVariant property on such a
defunct proxy, then he gets a NULL back. So unless said user code
checks the return value, criticals will still be printed if the NULL
GVariant is used for anything interesting.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Make g_date_time_format() support some useful format modifiers from
strftime(). This commit adds support for the POSIX 'O' modifier
(alternative digits), as well as the -/_/0 padding modifiers, which
are a GNU strftime() extension.
https://bugzilla.gnome.org/show_bug.cgi?id=648678
The code generator sprinkles a few asserts in its output of the form:
g_assert (prop_id - 1 >= 0 && prop_id - 1 < %d);\n
prop_id is unsigned, though, so this generates a compiler warning for
me.
This commit changes the code to merely check for prop_id != 0 instead of
prop_id - 1 >= 0
g_variant_new_string() hits a g_return_if_fail() when given invalid
UTF-8. That's certainly the right thing to do, but
g_variant_builder_add() uses this function internally and crashes when
it returns NULL due to the user passing a non-utf8 string.
We can protect the internal code by returning "[Invalid UTF-8]" in this
case while also making the problem easier to debug (and less fatal).
Closes#632631.
.. and add a C setter to do this. Also make the C getter return a
reference since the property may be set from another thread. Also
change the constructor to _not_ take a GDBusConnection since this is
something you almost always want to do _after_ creating it. The
API/ABI break is fine as there has never been a GLib release with this
type.
https://bugzilla.gnome.org/show_bug.cgi?id=648959
Signed-off-by: David Zeuthen <davidz@redhat.com>
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
autoconf 2.68 is very insistent that AC_LANG_SOURCE/AC_LANG_PROGRAM
must be used in certain places, to avoid quoting/lack-of-quoting
problems, or something. Fix.
g_thread_init() causes a hash table to be allocated (in read_aliases).
Since hash tables are now a bit larger, we need to bump one of the
probe sizes to avoid our probe slice being used for the aliases
hash table.
Make hash tables start out in a mode in which they don't store
values at all, until the first insertion of a non-identical
key-value pair.
This reduces memory requirements by 1/3 when using hash tables
to store sets.
Based on a patch by Morten Welinder,
https://bugzilla.gnome.org/show_bug.cgi?id=644437
Kill g_hash_table_lookup_node and rename g_hash_table_lookup_node_for_insertion
to g_hash_table_lookup_node. Since at this point we already check for
toombstones in all callers of g_hash_table_lookup_node this doesn't make
a difference.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
This reduces memory requirements by 1/6 on 64-bit machines since
no padding is needed. It also puts less strain on the memory
allocator since we no longer need one giant slab of memory.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
