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
On Linux with gdb, it's much more convenient to debug programs using
G_DEBUG=fatal-warnings if we send SIGTRAP instead of abort() by
default. The default handler for both is to terminate the process.
In particular this makes it more easily possible to debug a warning
that's not the first in a program; you can skip past it and
go to the warning you care about.
The "aborting..." message is removed since it's no longer accurate,
and anyways was never very useful; crashes should show up in ABRT/apport
type crash catching systems.
https://bugzilla.gnome.org/show_bug.cgi?id=648423
This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
