In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
Now that we're directly accessing the memory holding a message blob,
we can access strings directly while reading them. This speeds up
read_string significantly, since we no longer malloc/memcpy/free.
GData*Streams incur significant overhead, and we do not need all of the
functionality that they provide, since we only ever read from/write to
memory when handling message blobs, so it is more performant to use a
simple structure.
https://bugzilla.gnome.org/show_bug.cgi?id=652650
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>
As part of the deserialisation process of a zero-length array in the
DBus wire format, parse_value_from_blob() recursively calls itself with
the expectation of failing (as can be seen by the assert immediately
following).
It passes &local_error to this always-failing call and then fails to
free it (indeed, to use it at all). The result is that the GError is
leaked.
Fix it by passing in NULL instead, so that the GError is never created
in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=662411
Matthew Bucknall pointed out
GDBusMessage does not serialize/deserialize double values correctly
on platforms with strict alignment constraints (in my particular
case, ARM926EJ-S).
This was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=652197
Signed-off-by: David Zeuthen <davidz@redhat.com>
-gdbusmessage.c and gregistrysettingsbackend.c is updated to fix C99-style declarations
-also fixed typo for displaying registry entry in gregistrysettingsbackend.c (\% -> \\%)
Ryan pointed out that it's safe to do this because we have the
G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL flag and that it simplifies
how filter functions work.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't actually use this yet as that will require a couple of
modifications to the filter function signature. This is part of the
bug-fix for
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
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>
We use g_assert() instead of setting the GError because it is a
programming error if the GVariant contains invalid data - see commit
5e6f762d61 for where the last hole in
GVariant was closed.
So if we can trust GVariant to only contain valid data (ignoring the
case where unsafe API such as g_variant_new_from_data() is used), why
g_assert() at all with costly g_utf8_validate() checks? Because a) it
is relatively inexpensive; and b) it helps find bugs such as the one
fixed in commit 5e6f762d61.
If performance is a concern we can play games like introducing
environment variables or other machinery to avoid such "costly"
checks. I doubt it will ever be an issue.
Also replace two "Hmm" TODO item with a static assert - the code that
serializes a gdouble into the D-Bus wire format by treating it as a
guint64 is indeed correct - endianess needs to be taken into account
(see the D-Bus reference implementation for similar code). But we want
to make sure that we're indeed using an architecture/compiler where a
gdouble takes up 8 bytes - hence the assertion.
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>
E.g. move these C structures out of public header files and into their
respective C files. Also nuke padding since this is no longer needed.
This leaves only GDBusProxy as an extendable type.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Also add a 'address' G_DBUS_DEBUG option that will print out useful
debug information such as
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14542: Autolaunch enabled (using X11).
14542: --exit-with-session automatically enabled
14542: Connected to X11 display ':0.0'
14542: === Parent dbus-launch continues
14542: Waiting for babysitter's intermediate parent
14542: Reading address from bus
14542: Reading PID from daemon
14542: Saving x11 address
14542: Created window 88080385
14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
14542: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
and
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14549: Autolaunch enabled (using X11).
14549: --exit-with-session automatically enabled
14549: Connected to X11 display ':0.0'
14549: dbus-daemon is already running. Returning existing parameters.
14549: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
Note that things work exactly like libdbus, e.g. from the
dbus-launch(1) man page:
Whenever an autolaunch occurs, the application that had to start a
new bus will be in its own little world; it can effectively end up
starting a whole new session if it tries to use a lot of bus
services. This can be suboptimal or even totally broken, depending
on the app and what it tries to do.
[...]
You can always avoid autolaunch by manually setting
DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
address if none is set is "autolaunch:", so if any other address is
set there will be no autolaunch. You can however include autolaunch
in an explicit session bus address as a fallback, for example
DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
the first address doesn't work, processes will autolaunch. (The bus
address variable contains a comma-separated list of addresses to
try.)
Signed-off-by: David Zeuthen <davidz@redhat.com>
These fixes makes udisks-daemon from udisks' gdbus-port branch, see
http://cgit.freedesktop.org/udisks/log/?h=gdbus-port
handle 200 add/remove uevents generated by e.g.
#!/bin/bash
DEV=mmcblk0p1
for n in `seq 200` ; do
udevadm trigger --sysname-match=$DEV --action=remove
udevadm trigger --sysname-match=$DEV --action=add
echo foo $n
done
without any substantial leaks.
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>
