Todo List

Class DBusTypeMark
DBusTypeMark isn't used right now and probably won't be, we should delete it

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

Group DBusAuth
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.

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

Group DBusAuth
grep FIXME in dbus-auth.c

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

Group DBusBus
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.

Global dbus_bus_get
alex thinks we should nullify the connection when we get a disconnect-message.

Global dbus_bus_request_name
this all seems sort of broken. Shouldn't the flags be a property of the name, not the app requesting the name? What are the use-cases other than the "text editor" thing and how are we supporting them?

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

Global dbus_connection_add_filter
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.

Global dbus_connection_dispatch
some FIXME in here about handling DBUS_HANDLER_RESULT_NEED_MEMORY

Global dbus_connection_dispatch
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

Global dbus_connection_set_watch_functions
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.

Global dbus_connection_unref
in practice it can be quite tricky to never unref a connection that's still connected; maybe there's some way we could avoid the requirement.

Global _dbus_connection_handle_watch
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.

Global dbus_set_error
should be called dbus_error_set()

Global dbus_set_error_const
should be called dbus_error_set_const()

Global _dbus_atomic_dec
implement arch-specific faster atomic ops

Global _dbus_atomic_inc
implement arch-specific faster atomic ops

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

Global _dbus_directory_get_next_file
for thread safety, I think we have to use readdir_r(). (GLib has the same issue, should file a bug.)

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

Global _dbus_full_duplex_pipe
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.

Global _dbus_setenv
if someone can verify it's safe, we could avoid the memleak when doing an unset.

Group DBusKeyring
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.

Global _dbus_keyring_validate_context
this is the most inefficient implementation imaginable.

Global _dbus_marshal_read_fixed_multi
we aren't using this function (except in the test suite)

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

Global _dbus_type_reader_set_basic
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.)

Global _dbus_type_reader_set_basic
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.

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

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

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

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

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

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

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

Global _dbus_validate_signature_with_reason
verify that dict entries have exactly two fields

Global _dbus_validate_signature_with_reason
require that dict entries are in an array

Global _dbus_verbose_bytes
right now it prints even if not in verbose mode

Global INITIAL_LOADER_DATA_LEN
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.

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

Global _dbus_message_loader_get_buffer
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.

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

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

Global _dbus_message_loader_queue_messages
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.

Global dbus_message_append_args
support DBUS_TYPE_STRUCT and DBUS_TYPE_VARIANT and complex arrays

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

Global dbus_message_append_args_valist
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.

Global dbus_message_get_args
support DBUS_TYPE_STRUCT and DBUS_TYPE_VARIANT and complex arrays

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

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

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

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

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

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

Global _dbus_object_tree_dispatch_and_unlock
thread problems

Global dbus_pending_call_block
when you start blocking, the timeout is reset, but it should really only use time remaining since the pending call was created.

Global dbus_pending_call_get_completed
not thread safe? I guess it has to lock though it sucks

Group DBusServer
Thread safety hasn't been looked at for DBusServer

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

Global dbus_server_listen
error messages on bad address could really be better. DBusResultCode is a bit limiting here.

Global _dbus_string_test
Need to write tests for _dbus_string_copy() and _dbus_string_move() moving to/from each of start/middle/end of a string. Also need tests for _dbus_string_move_len ()

Group DBusString
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.

Global _dbus_string_ends_with_c_str
memcmp might make this faster.

Global _dbus_string_equal
memcmp is probably faster

Global _dbus_string_equal_len
write a unit test

Global _dbus_string_equal_len
memcmp is probably faster

Global _dbus_string_equal_substring
write a unit test

Global _dbus_string_equal_substring
memcmp is probably faster

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

Global _dbus_string_pop_line
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

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

Global _dbus_string_replace_len
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.

Global _dbus_string_steal_data_len
this function is broken because on failure it may corrupt the source string.

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

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

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

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

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

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

Global dbus_g_proxy_begin_call
this particular function shouldn't die on out of memory, since you should be able to do a call with large arguments.

Global dbus_g_proxy_call_no_reply
this particular function shouldn't die on out of memory, since you should be able to do a call with large arguments.


Generated on Tue Jul 7 15:14:01 2009 for D-BUS by  doxygen 1.4.6