Instead of using full path in glib_compile_schemas and
glib_compile_resources variables, rely on having the executables in
PATH.
This fixes the cross-compiling case where we cannot execute the binaries
for target system. Instead of executing the target system's binaries, we
need to use the native versions installed on the build host. The easiest
way to find the native executables is to just pick them up from PATH.
In addition, this brings gio-2.0.pc in line with glib-2.0.pc -- the
latter has historically only listed the executable name and not the full
path.
https://bugzilla.gnome.org/show_bug.cgi?id=673911
When presented with an array of empty arrays of 8-byte-aligned types,
GDBus would incorrectly apply the 8-byte alignment when reading back.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
D-Bus arrays are serialized as follows:
1. align to a 4-byte boundary (for the length)
2. uint32: the length of the serialized body in bytes
3. padding for the alignment of the body type (not included in the length)
4. the body.
Note that 3. is a no-op unless the body type is an 8-byte aligned type
(uint64, int64, double, struct, dict_entry), since you are always on a
4-byte boundary from aligning and writing the length.
So, an empty aax (that is, an array containing zero arrays of int64)
is serialized as follows:
1. align to a 4-byte boundary
2. length of the contents of this (empty) array, in bytes (0)
3. align to a 4-byte boundary (the child array's alignment requirement)
4. there is no body.
But previously, GDBus would recurse in step three to align not just for
the type of the child array, but for the nonexistent child array's
contents. This only affects the algorithm when the grandchild type has
8-byte alignment and the reader happened to not already be on an 8-byte
boundary, in which case 4 bytes were spuriously skipped.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
Or some system with different locale settings might get confused whether
a two digit year is to be parsed with regard to the current century or
as an absolute year.
Add a test that excercises the script execution code.
Unfortunately, much of this code only runs in the forked
child, and therefore its execution does not get caught
by gcov.
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.
Add a test that excercises the 'no conversion' code path.
This uncovered that we don't treat errno properly in this path,
and as a consequence, the returned error code is unreliable.
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
