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>
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
This bug was exposed by fixing the following leak in the resources test:
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204== by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020== by 0x4084724: standard_malloc (gmem.c:85)
==27020== by 0x40847C7: g_malloc (gmem.c:159)
==27020== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020== by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020== by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020== by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020== by 0x4228B36: do_lookup (gresource.c:280)
==27020== by 0x4228F56: g_resource_get_info (gresource.c:492)
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427== by 0x4084724: standard_malloc (gmem.c:85)
==26427== by 0x40847C7: g_malloc (gmem.c:159)
==26427== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427== by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427== by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427== by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427== by 0x4228BA5: do_lookup (gresource.c:293)
==26427== by 0x4228F51: g_resource_get_info (gresource.c:493)
Helper scripts in C can be problematic for cross compiling: the compiler
produces executables for the target platform, which the host is usually
unable to run.
https://bugzilla.gnome.org/show_bug.cgi?id=669224
The glib-compile-resources --generate-dependencies call was failing,
although not stopping the build.
Failed to open file 'test2.gresource.xml': No such file or directory
Failed to open file 'test3.gresource.xml': No such file or directory
Failed to open file 'test4.gresource.xml': No such file or directory
Failed to open file 'test.gresource.xml': No such file or directory
We need to do this because constructors run before main() and
thus before any call to g_mem_set_vtable, making it impossible to
use that function if constructors call g_malloc.
We do this by making the constructors just register the static data
for lazy registration, doing the lazy registration when using
the global resource set.
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
It's important to have strict rules for handling of whitespace in
translated strings in GSettings schema files so that the tools
extracting the messages will end up with the same messages as the
runtime calling gettext().
The rules are designed to be simple and unambiguous yet cover most
normal uses in a convenient way.
Those rules are as follows (with rationale):
- for <default> tags, the text content has its leading and trailing
whitespace stripped off, but internal whitespace is not modified in
any way.
This allows for slightly more flexible use of whitespace without
causing that whitespace to appear in the strings for translation.
- for <summary> and <description> tags, the content is split into
paragraphs. Paragraphs are separated by two or more sequential
newline characters. Each paragraph has its leading and trailing
whitespace removed and all other whitespace is normalised to a
single ascii space character. Finally, the paragraphs are rejoined,
inserting exactly two newlines between them.
This allows for longer explanations (particularly in the description
tag) using a natural format that, when normalised, will display
nicely in toolkits.
This patch implements the rules for <default> tags. The schema compiler
currently ignores <summary> and <description> tags.
First, correct a rather dubious case of accessing a GSettingsSchemaKey
after clearing it. This was technically okay because only the key name
was accessed (and it is not owned by the struct) but it looks very
wrong.
Second, have g_settings_backend_write() sink the passed in GVariant*.
Not all backends get this right, and I'm starting to like the pattern of
virtual function wrappers being responsible for sinking the parameters
that they are documented as consuming.
GValueArray was deprecated in bug 667228 and since we never change the
size of the array, it was kinda dumb to just GValueArray in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=667228
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is needed for thread-safety ... yes, it would have been better to
make get_object() return a full reference and have something like a
peek_object() method return a borrowed reference for C convenience
(only a single vfunc would have been needed). But such an ABI break is
too late now...
Signed-off-by: David Zeuthen <davidz@redhat.com>
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.
Bug #667929.
Some platforms don't have the source-specific multicast sockopts, and
so would fail to compile. Fix that (and return an error if the caller
tries to use source-specific). Also clarify the docs a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=668468
This lets you poke at resources in elf files and
standalone resource bundles. So far, only listing
and extracting resources is supported. The support
for elf files requires libelf.
