dbus-sysdeps-unix.h

[Havoc Pennington]

btw, a specific change I think could make sense but may not is to make 
the dbus-sysdeps.h file descriptor operations socket-specific. Maybe put 
_socket in the names when the function could conceivably work on a file, 
like:

  _dbus_read_socket()
  _dbus_poll_sockets()
  _dbus_close_socket()

Then in dbus-sysdeps-unix.h there could be maybe a dbus_read_file() 
and/or dbus_read_socket_or_file(). For unix the implementation of course is:


_dbus_read_socket_or_file()
{
  /* current code */
}

_dbus_read_socket()
{
   _dbus_read_socket_or_file();
}

_dbus_read_file()
{
   _dbus_read_socket_or_file()
}

After renaming these, could go through each compilation error about 
missing _dbus_read() and be sure the appropriate function is used. i.e. 
if the fd is known to be a socket, use read_socket, known to be a file, 
use read_file, etc.

If there are any uses of dbus_read_socket_or_file, which there may not 
be, then if that function is in dbus-sysdeps-unix.h we would then be 
able to tell that the file using dbus_read_socket_or_file was unix-specific.

Once this is done I think dbus-server-unix.c for example could be 
renamed to dbus-server-socket.c and no longer include unistd.h or 
dbus-sysdeps-unix.h, it could include just dbus-sysdeps.h and use the 
socket functions.

There would still be a dbus-server-unix.c perhaps but containing only 
the function _dbus_server_new_for_domain_socket().

Alternatively - maybe dbus-sysdeps-unix.h is not always right. Another 
approach for e.g. the unix domain socket functions 
_dbus_listen_unix_socket, etc. would be to make them always fail on 
Windows - the Windows implementation just returns an error.
That would have the desired effect i.e. if you tried to use a unix: 
address on Windows, the error "unix sockets not supported on Windows" 
would be printed. This is the same way we're dealing with the public API 
that has _unix in it.

If we made this change then there's no dbus-server-unix.c, just 
dbus-server-socket.c.

That would not work as well for _dbus_read_socket_or_file() though, 
probably trying to use _dbus_read_socket_or_file() should fail at 
compile time on Windows, since the right thing won't happen if it just 
fails at runtime. So sysdeps-unix.h might make sense for 
_dbus_read_socket_or_file.

I'm not sure sysdeps-unix.h will have anything in it to be honest, if 
sockets are not unix-specific, read_socket_or_file() never gets used, 
and e.g. connect_unix_socket and read_credentials_unix_socket simply 
fail with an error on Windows, then that would work out just fine.

The only thing that I still consider a little fishy is all the 
unix-specific gid/uid/pid stuff in dbus-sysdeps.h, but as long as any 
weird made-up ids don't make it out of the dbus process, I think it will 
be OK.

I guess I'm almost stating the obvious - a dbus-sysdeps-unix.h should 
not be necessary *if* there's no need for -unix files elsewhere in the 
source tree - i.e. if everything in dbus-sysdeps.h is an appropriate 
abstraction that works (or fails in the right way) on both platforms.

The thing I'd consider bad is to try to actually implement a thing like 
connect_unix_socket on windows; it needs to fail either at compile time 
or at run time. dbus-sysdeps-unix.h is an idea for how to fail it at 
compile time, and at runtime it could just throw a DBusError.

We want to avoid things labeled unix that really work on both platforms, 
and also things not labeled unix that really work only on unix.

Havoc