For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.
Fix that up.
Also: fix some overzealous asserting in the testcases. Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.
Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.
It was added after G_END_DECLS, outside the #ifdef G_PLATFORM_WIN32,
and inside a #ifndef __GTK_DOC_IGNORE__ block. So it was missing from
the doc.
https://bugzilla.gnome.org/show_bug.cgi?id=743661
This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.
Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=743636
g_socket_client_add_application_proxy() claimed "When the indicated
proxy protocol is returned by the #GProxyResolver, #GSocketClient will
consider this protocol as supported but will not try to find a #GProxy
instance to handle handshaking." But in fact, it did the checks in the
wrong order, so GProxy proxies ended up overriding
application-specified ones. Fix that.
Also, simplify the code a bit by making use of g_hash_table_add() and
g_hash_table_contains().
https://bugzilla.gnome.org/show_bug.cgi?id=733876
Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time. On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init(). Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.
This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Check the IPv6 addresses on Windows, as we need to reject those that have
brackets/ports around them as valid addresses in this form would have been
accepted during the call to g_inet_address_new_from_string ().
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn
helper programs), so that they match the names of the DLLs/EXEs that are
built. Also update the .lib generation so that all will use -$(ApiVersion)
from the property sheets instead of the -2.0 which was previously hard
coded (as we will eventually move into GLib 3.x in the future, for example)
• Clarify that GError** parameters are for the return of _newly
allocated_ GError*s.
• Clarify that errors may need to be checked for explicitly if the
return value of a function doesn’t reliably indicate them.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It was documented before, but wasn’t especially clear. Doing
if (X)
g_free (X);
is apparently quite a pervasive real-world anti-pattern, so perhaps it
could be documented more explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Just in case people have forgotten their basic algorithms course. Seen
in some pretty terrible code in the wild; hopefully mentioning the cost
in the documentation will make people think twice about using a counter
variable when iterating over a linked list.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s quite common to see a g_param_spec_pointer() used for GObject or
boxed types which, while not incorrect, does make memory management
unsafe, since no copying or reference counting can be performed
automatically.
Similarly, people often use g_param_spec_boolean() when an enum would be
more appropriate, cf.
http://blog.ometer.com/2011/01/20/boolean-parameters-are-wrong/
Using enums also means that the set of allowable values can be extended
in future if needed.
In the hope that people who write code like that read the documentation,
mention the more specific types in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s NULL iff free_segment is TRUE, so the annotation doesn’t quite
capture all the function definition, but is a safe over-estimate of the
return value’s nullability.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
