The code that is checking the userinfo part was accidentally
given a pointer to the end of the userinfo, so it was not
checking the right portion of the string at all.
gio/gproxyresolver.h: GProxyResolver already documented in gio/giotypes.h
gio/gtlsbackend.h: GTlsBackend already documented in gio/gtlsbackend.c
gio/gtlsclientconnection.h: GTlsClientConnection already documented in gio/gtlsclientconnection.c
gio/gtlsconnection.h: GTlsConnection already documented in gio/gtlsconnection.c
gio/gunixconnection.h: GTcpConnection already documented in gio/giotypes.h
glib/gversion.h: GLIB_CHECK_VERSION already documented in glib/gversion.c
Found these thanks to the improved gobject-introspection
GTK-Doc comment block/annotation parser.
See https://bugzilla.gnome.org/show_bug.cgi?id=672254https://bugzilla.gnome.org/show_bug.cgi?id=673385
GDBus heavily relies on idles for some of its cleanup operations,
and not running a mainloop leads to things not getting cleaned
up properly, which in turn leads to test failures, since the
session bus singleton does not get removed.
This program is only used indirectly from gapplication.c in
tests, but that is no reason to let it segfault when it is
run from the commandline without arguments.
This is needed because glib-mkenums doesn't handle #ifdef values in
enums, and so it needs to have all values always defined in the enum.
When not available, define the missing values to a negative value.
g_input_stream_read() does state that it returns 0 on end of file, but
not in the Returns: line, so it's easy to miss on a quick skim-read.
g_input_stream_read_async() documents that g_input_stream_read_finish()
returns 0 on end of file, but g_input_stream_read_finish() itself does
not.
https://bugzilla.gnome.org/show_bug.cgi?id=673174
On some systems gelf.h may not be stored under the top level include
directory in which case we need to add the correct include paths in
cflags by using pkg-config(1).
GDBusProxy sets an error on a GSimpleAsyncResult and then returns
without dispatching the result for completion (and leaks the result in
the process). Fix that.
Also add a testcase. Unfortunately, adding the testcase uncovered
bug #672248. We can work around that by reordering the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=672249
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
Now that we're using g_simple_async_result_set_check_cancellable() we
no longer need this terrible hack of carrying the GCancellable on the
GSimpleAsyncResult using qdata. See bug 672013 for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=672013
Signed-off-by: David Zeuthen <davidz@redhat.com>
Call g_simple_async_result_set_check_cancellable() after all
GSimpleAsyncResult creation in order to take advantage of the new
reliable cancellation feature.
The guarantee of reliable cancellation fixes a bug in dbusmenu (which
was already assuming that cancellation was reliable). See this bug:
https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/953562https://bugzilla.gnome.org/show_bug.cgi?id=672013
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add a function g_simple_async_result_set_check_cancellable() to provide
a GCancellable that is checked for being cancelled during the call to
g_simple_async_result_propagate_error().
This gives asynchronous operation implementations an easy way to
provide reliable cancellation of those operations -- even in the case
that a positive result has occured and is pending dispatch at the time
the operation is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=672013
If there are no modules installed then the most appropriate thing is to
have no cachefile instead of an empty one. This unbreaks the "clean
directory after 'make uninstall'" check that automake does.
https://bugzilla.gnome.org/show_bug.cgi?id=671664
Otherwise we get criticals a'la
GLib-GIO-CRITICAL **: g_cancellable_release_fd: assertion `cancellable->priv->fd_refcount > 0' failed
when reading/writing to certain kinds of file descriptors.
Patch reviewed by Dan Winship on IRC.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We were attempting to unregister our ownership of our D-Bus name even in
the case that we were non-unique (ie: we didn't actually own the name).
Rework the logic a bit to prevent that: for non-unique, we leave
impl->bus_name as NULL and we only register/unregister if it is
non-NULL.
If an application (such as Nautilus) wants to show a sidebar with
devices group into different groups such as "Devices" and "Network",
it's currently up to the application itself to do the classification
(for example by looking at the URI scheme for the activation root,
e.g. smb://).
This patch adds a new identifier G_VOLUME_IDENTIFIER_KIND_CLASS that
can be set by volume monitors and used by applications.
See https://bugzilla.gnome.org/show_bug.cgi?id=668295
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Unix and Windows gio GSocket behaves differently when the socket is
closed by the peer. On Unix, the client receives pending data before
receiving HUP. But on Windows, the HUP may come before, resulting in
unreliable and racy code. We should have same behaviour on all
platforms.
According to MSDN documentation: "an application should check for
remaining data upon receipt of FD_CLOSE to avoid any possibility of
losing data."
https://bugzilla.gnome.org/show_bug.cgi?id=669810
For a number of reasons it might be useful to register the object paths
associated with a non-unique application so that the application can at
least field requests to its unique D-Bus name.
https://bugzilla.gnome.org/show_bug.cgi?id=647986
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=37632
Signed-off-by: David Zeuthen <davidz@redhat.com>
