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.
FIXME what if we call out to application code to handle a message, holding the dispatch lock, and the application code runs the main loop and dispatches again? Probably deadlocks at the moment. Maybe we want a dispatch status of DBUS_DISPATCH_IN_PROGRESS, and then the GSource etc. could handle the situation? Right now our GSource is NO_RECURSE
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.
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.
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.