Todo List

implement arch-specific faster atomic ops

implement arch-specific faster atomic ops

1.0? We need to be able to distinguish "out of memory" error from "the data is hosed" error.

it might be cute to collapse multiple '/' such as "foo//" concat "//bar"

could use performance improvements (it keeps scanning the whole message queue for example)

This is basically a hack - we could delete _dbus_transport_handle_watch() and the virtual handle_watch in DBusTransport if we got rid of it. The reason this is some work is threading, see the _dbus_connection_handle_watch() implementation.

should cover more errnos, specifically those from open().

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.

this is the most inefficient implementation imaginable.

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.

we need to enforce a max length on strings in header fields.

we need to check that the proper named header fields exist for each message type.

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.

thread problems

memcmp is probably faster

write a unit test

memcmp is probably faster

this doesn't do anything with max_length field. we should probably just kill the max_length field though.

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

optimize the case where the two lengths are the same, and avoid memmoving the data in the trailing part of the string twice.

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.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

we drop connection->mutex when calling the unix_user_function, which may not be safe really.

once we add a way to escape paths in a dbus address, this function needs to do escaping.

for now this does not delete the typecodes associated with the value, so this function should only be used for array elements.

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 is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

change spec to disallow more things, such as spaces in the path name

this is inconsistent with most of DBusString in that it allows a start,len range that extends past the string end.

this function only exists because of the weird way connection watches are done, see the note in docs for _dbus_connection_handle_watch().

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.

some FIXME in here about handling DBUS_HANDLER_RESULT_NEED_MEMORY

add a Windows API analogous to dbus_connection_set_unix_user_function()

We need to drop the lock when we call the add/remove/toggled functions which can be a side effect of setting the watch functions.

support DBUS_TYPE_STRUCT and DBUS_TYPE_VARIANT and complex arrays

If this fails due to lack of memory, the message is hosed and you have to start over building the whole message.

for now, if this function fails due to OOM it will leave the message half-written and you have to discard the message and start over.

support DBUS_TYPE_STRUCT and DBUS_TYPE_VARIANT and complex arrays

this could be optimized by using the len from the message instead of calling strlen() again

If this fails due to lack of memory, the message is hosed and you have to start over building the whole message.

If this fails due to lack of memory, the message is hosed and you have to start over building the whole message.

If this fails due to lack of memory, the message is hosed and you have to start over building the whole message.

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.

If appending any of the arguments fails due to lack of memory, the message is hosed and you have to start over building the whole message.

If this fails due to lack of memory, the message is hosed and you have to start over building the whole message.

add _DBUS_GNUC_PRINTF to this (requires moving _DBUS_GNUC_PRINTF to public header, see DBUS_GNUC_DEPRECATED for an example)

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

some SASL profiles require sending the empty string as a challenge/response, but we don't currently allow that in our protocol.

right now sometimes both ends will block waiting for input from the other end, e.g. if there's an error during DBUS_COOKIE_SHA1.

the cookie keyring needs to be cached globally not just per-auth (which raises threadsafety issues too)

grep FIXME in dbus-auth.c

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.

rename to UUID instead of GUID

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.

write tests for break-loader that a) randomly delete header fields and b) set string fields to zero-length and other funky values.

Thread safety hasn't been tested much for DBusServer

Need notification to apps of disconnection, may matter for some transports

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.

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.

We need to have a way to wake up the select sleep if a new iteration request comes in with a flag (read/write) that we're not currently serving. Otherwise a call that just reads could block a write call forever (if there are no incoming messages).