Older versions of libdbus would let you construct an invalid
DBusMessage, but that's a bug, which will be fixed in 1.4.8/1.5.0.
Instead, construct a valid message of the same length, then replace
substrings in the serialized blob with their invalid counterparts.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=646326
Signed-off-by: David Zeuthen <davidz@redhat.com>
The D-Bus spec mentions exactly what header fields are required for
various message types. Add tests for this as well.
Also disallow empty interfaces for signals since the D-Bus spec says
this is Verboten already.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Also use this in the test cases to check that serialization to and
from both big and little endian works.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This allows sending and receiving D-Bus messages with instances of the
'h' D-Bus type. Unlike libdbus-1's dbus_message_iter_get_basic()
method, g_variant_get_handle() does not return a duplicated unix file
descriptor (that must be closed with close(2)) - instead, it returns
an index that can be used to get/dup the file descriptor from a
GUnixFDList object that can be obtained from the GDBusMessage object.
Signed-off-by: David Zeuthen <davidz@redhat.com>
See https://bugzilla.gnome.org/show_bug.cgi?id=621838 for the whole
story. The problem was that we ended up reading data from arrays of
arrays when we were just supposed to be aligning the buffers.
Also add a host of debug infrastructure that was needed to find the
root cause. For now it can be turned on only via defining
DEBUG_SERIALIZER. In the future we might want to make it work via
G_DBUS_DEBUG. In a nutshell, the added debug info looks like this
Parsing blob (blob_len = 0x0084 bytes)
0000: 6c 01 00 01 3c 00 00 00 41 00 00 00 37 00 00 00 l...<...A...7...
0010: 08 01 67 00 08 61 61 79 61 7b 73 76 7d 00 00 00 ..g..aaya{sv}...
0020: 01 01 6f 00 08 00 00 00 2f 66 6f 6f 2f 62 61 72 ..o...../foo/bar
0030: 00 00 00 00 00 00 00 00 03 01 73 00 06 00 00 00 ..........s.....
0040: 4d 65 6d 62 65 72 00 00 00 00 00 00 34 00 00 00 Member......4...
0050: 03 00 00 00 63 77 64 00 01 73 00 00 23 00 00 00 ....cwd..s..#...
0060: 2f 68 6f 6d 65 2f 64 61 76 69 64 7a 2f 48 61 63 /home/davidz/Hac
0070: 6b 69 6e 67 2f 67 6c 69 62 2f 67 69 6f 2f 74 65 king/glib/gio/te
0080: 73 74 73 00 sts.
Parsing headers (blob_len = 0x0084 bytes)
Reading type a{yv} from offset 0x000c: array spans 0x0037 bytes
Reading type {yv} from offset 0x0010
Reading type y from offset 0x0010: 0x08 '
Reading type v from offset 0x0011
Reading type g from offset 0x0014: 'aaya{sv}'
Reading type {yv} from offset 0x001e
Reading type y from offset 0x0020: 0x01 ''
Reading type v from offset 0x0021
Reading type o from offset 0x0024: '/foo/bar'
Reading type {yv} from offset 0x0031
Reading type y from offset 0x0038: 0x03 ''
Reading type v from offset 0x0039
Reading type s from offset 0x003c: 'Member'
Parsing body (blob_len = 0x0084 bytes)
Reading type (aaya{sv}) from offset 0x0047
Reading type aay from offset 0x0048: array spans 0x0000 bytes
Reading type a{sv} from offset 0x004c: array spans 0x0034 bytes
Reading type {sv} from offset 0x0050
Reading type s from offset 0x0050: 'cwd'
Reading type v from offset 0x0058
Reading type s from offset 0x005b: '/home/davidz/Hacking/glib/gio/tests'
OK
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is needed to e.g. allow encoding maybe types (once we add
G_DBUS_CAPABILITY_FLAGS_MAYBE_TYPES) if, and only if, that capability
has been negotiated with the peer (via authentication).
Things compile and the test-suite passes. Still need to hook up
gio.symbols and docs. There are still a bunch of TODOs left in the
sources that needs to be addressed.
Signed-off-by: David Zeuthen <davidz@redhat.com>
