Experimentally disable the ability to unload dynamic types by refusing
to drop the last reference on types (effectively turning the type
unloading into dead code).
The plan is to leave things like this for a stable cycle and only
proceed with removing the code if we are sure that there are no
unforeseen problems.
https://bugzilla.gnome.org/show_bug.cgi?id=693351
Some compilers have support for atomic operations, but do not
define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4. Instead of checking
for this define, we check for __sync_bool_compare_and_swap and
define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 if the compiler doesn't
define it.
https://bugzilla.gnome.org/show_bug.cgi?id=682818
If there are options that need their names to be aliased, keep track
of that internally rather than modifying the passed-in GOptionGroup
(and leaking strings in the process).
https://bugzilla.gnome.org/show_bug.cgi?id=682560
The default handler test was not unsetting the log handler that
gets installed by GTest, which causes the log messages to be duplicated
on stdout if --verbose or --tap are passed. This in turn can make some
of the non-match checks fail. Since we are already using g_test_trap_fork,
we can just unset the handler in the child.
GHashTable remains a set for as long as all of the keys are exactly
equal (in pointer value) to all of the values. We check this by
comparing keys to values when we do inserts.
Unfortunately, when doing g_hash_table_insert() when a key is already in
the table, the old key pointer value is kept, but the new value pointer
is used. Now we have a situation where a key pointer is unequal to a
value pointer, but we were not treating this case properly.
Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=692815
While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
Since this is a new API this cycle it's a good time to add a doc comment
explicitly declaring that a confusing issue that could be resolved
either way has no specific defined behaviour.
This may allow us some additional freedom in future GMainContext work or
we may decide that one behaviour is more desirable than the other.
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
