right now the default address of the system bus is hardcoded, so if you change it in the global config file suddenly you have to set DBUS_SYSTEM_BUS_ADDRESS env variable. Might be nice if the client lib somehow read the config file, or if the bus on startup somehow wrote out its address to a well-known spot, but might also not be worth it.
we don't run filters on messages while blocking without entering the main loop, since filters are run as part of dbus_connection_dispatch(). This is probably a feature, as filters could create arbitrary reentrancy. But kind of sucks if you're trying to filter METHOD_RETURN for some reason.
We would like to be able to say "You can ask the bus to tell you the user of another connection though if you like; this is done with dbus_bus_get_windows_user()." But this has to be implemented in bus/driver.c and dbus/dbus-bus.c, and is pointless anyway since on Windows we only use the session bus for now.
there's a memory leak on some codepath in here, I saw it once when running make check - probably some specific initial cookies present in the cookie file, then depending on what we do with them.
DBusTypeReader currently takes "const" versions of the type and value strings, and this function modifies those strings by casting away the const, which is of course bad if we want to get picky. (To be truly clean you'd have an object which contained the type and value strings and set_basic would be a method on that object... this would also make DBusTypeReader the same thing as DBusTypeMark. But since DBusMessage is effectively that object for D-Bus it doesn't seem worth creating some random object.)
optimize this by only rewriting until the old and new values are at the same alignment. Frequently this should result in only replacing the value that's immediately at hand.
this should be based on min header size plus some average body size, or something. Or rather, the min header size only, if we want to try to read only the header, store that in a DBusMessage, then read only the body and store that, etc., depends on how we optimize _dbus_message_loader_get_buffer() and what the exact message format is.
this function can be a lot more clever. For example it can probably always return a buffer size to read exactly the body of the next message, thus avoiding any memory wastage or reallocs.
If a message has unknown type, we should probably eat it right here rather than passing it out to applications. However it's not an error to see messages of unknown type.
introduce a variant of this get_n_elements that returns the number of elements, though with a non-fixed array it will not be very efficient, so maybe it's not good.
when you start blocking, the timeout is reset, but it should really only use time remaining since the pending call was created. This requires storing timestamps instead of intervals in the timeout
DBusString needs a lot of cleaning up; some of the API is no longer used, and the API is pretty inconsistent. In particular all the "append" APIs, especially those involving alignment but probably lots of them, are no longer used by the marshaling code which always does "inserts" now.
owen correctly notes that this is a stupid function (it was written purely for test code, e.g. dbus-message-builder.c). Probably should be enforced as test code only with ifdef DBUS_BUILD_TESTS
avoid inserting the source into dest, then deleting the replaced chunk of dest (which creates a potentially large intermediate string). Instead, extend the replaced chunk of dest with padding to the same size as the source chunk, then copy in the source bytes.
libdbus only uses this for the debug-pipe server, so in principle it could be in dbus-sysdeps-util.c, except that dbus-sysdeps-util.c isn't in libdbus when tests are enabled and the debug-pipe server is used.