gio/tests/tls-certificates: fix

da053e34 broke the tls-certificates test by requiring the backend to
implement g_tls_certificate_verify() (which the test TLS backend
didn't). Add a trivial implementation to make the test pass again;
we'll need something more complicated when we add tests that are
supposed to get errors.
Guard g_inet_address_mask_equal against invalid input

https://bugzilla.gnome.org/show_bug.cgi?id=733338
gcancellable: Clarify that GSources hold references to GCancellables

Clarify in the documentation that a GSource created with
g_cancellable_source_new() must be explicitly removed from its
GMainContext before the GCancellable can be finalised.

This could be a common way of leaking GCancellables.

https://bugzilla.gnome.org/show_bug.cgi?id=737259
Updates for 2.43.0
GDBusInterfaceVTable: clarify memory handling for the method() virtual function

There are two consistent interpretations that could be taken for memory
handling of the 'invocation' parameter passed to the method_call() virtual
function of GDBusInterfaceVTable

 - A reference is passed (transfer full) to the method_call() virtual function,
   and that reference is then passed (transfer full) to the return_value/error
   functions on GDBusMethodInvocation.
 - An internal reference is retained from the point where method_call() is called
   until the return_value/error function is called.

Since the return_value/error functions were already marked (transfer full),
we use the first interpretation, annotate the invocation parameter of
method call as (transfer full) and describe this in the documentation, along
with the idea that you are always supposed to call one of the return_value/error
functions.

See bug 738122 for the leak this caused in GJS.

https://bugzilla.gnome.org/show_bug.cgi?id=738259
gmain: don't pass the same fd to g_poll() multiple times

If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.

Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).

Remove some win32-specific code which did the same thing (but was
O(n^2)).

https://bugzilla.gnome.org/show_bug.cgi?id=11059
gio: Prevent hang writing to a large GMemoryOutputStream

Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero.  This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.

Use gsize rather than int to allow for large streams on 64 bit machines.

https://bugzilla.gnome.org/show_bug.cgi?id=727988
gio: Prevent hang writing to a large GMemoryBuffer

Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero.  This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.

Use gsize rather than int to allow for large buffers on 64 bit machines.

https://bugzilla.gnome.org/show_bug.cgi?id=727988
doc: Clarify documentation regarding g_file_replace and etags

Clarify that with g_file_replace, a non-NULL etag is only checked if the
file already exists.

https://bugzilla.gnome.org/show_bug.cgi?id=736286
GTlsCertificate: fix loading of bad certificate chains

g_tls_certificate_new_from_file() was only loading the complete chain
if it was fully valid, but we only meant to be validating that it
formed an actual chain (since the caller may be planning to ignore
other errors).

https://bugzilla.gnome.org/show_bug.cgi?id=729739
gnetworking.h.in: move "#undef interface"

The win32 headers do:

  #define interface struct

which is just evil and breaks other code that assumes it can use
"interface" as a variable name. gnetworking.h was supposed to be doing
"#undef interface" after including the win headers, but it did it too
soon, resulting in it getting redefined by a later include. Fix this.

https://bugzilla.gnome.org/show_bug.cgi?id=738551
gnetworking.h.win32: Move "#undef interface"

This is a follow-up commit due to the fix in gnetworking.h.in in commit
7103484 (gnetworking.h.in: move "#undef interface").
GQueue: accept a NULL sibling for insert_before() and insert_after()

It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().

https://bugzilla.gnome.org/show_bug.cgi?id=736620
Simplify code that uses g_queue_insert_before() and insert_after()

g_queue_insert_before() and g_queue_insert_after() now accept a NULL
sibling.

https://bugzilla.gnome.org/show_bug.cgi?id=736620
docs: Update GParamFlags docs.

Remove reference to G_PARAM_READWRITE from GParamFlags' description,
since commit 6c395244a5db added G_PARAM_READWRITE to GParamFlags.

https://bugzilla.gnome.org/show_bug.cgi?id=726037
docs: Add missing opening parenthesis

https://mail.gnome.org/archives/gnome-web-list/2014-November/msg00003.html
gapplication: enable --help when app has options

This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().

Fix by moving the check for main_options up.

https://bugzilla.gnome.org/show_bug.cgi?id=740157
Updated Norwegian bokmål translation.
glib: Improve documentation for g_strfreev()

Fixes #740309.
GSettings: delay backend subscription

GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.

In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules.  This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).

Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.

Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.

In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.

We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:

 1) watched for a change signal; and then
 2) actually read a value

If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).

This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values.  We add a workaround to the commandline tool in order
to ensure that it continues to function properly.

It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.

We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.

https://bugzilla.gnome.org/show_bug.cgi?id=733791