dbus-sysdeps-unix.h

[Havoc Pennington]

Peter Kümmel wrote:
>> I think in an ideal world, a fair bit of dbus-sysdeps.h is either in
>> dbus-sysdeps-unix.h or gets modified to be less unix-like, e.g.
>> returning a DBusError instead of setting errno, etc.
>>
> 
> Is in an ideal world a sysdeps file which does not depend on the system?
> Maybe this is in general the wrong name for this file.

There are two purposes for the "sysdeps" file:
  a) keep all system header and libc usage in one place, i.e. avoid
    system headers elsewhere in the dbus code.
    This encapsulates all the config.h/HAVE_FOO tests, and also
    avoids low-level APIs that might result in security problems,
    ensuring the bulk of dbus only deals with DBusString and not
    low-level strings for example.
    Historically, this is the purpose of sysdeps.
  b) Windows/UNIX portability - different implementation of sysdeps
    on the two platforms

A dbus-sysdeps-unix.h/dbus-sysdeps-win32.h would be used when a) is 
desired, but b) is not desired. i.e. we want a dbus wrapper around a 
platform-specific function.

It's possible we have very few cases of a)-without-b) as I just 
mentioned in that other mail.

the unix socket functions are already expected to fail sometimes on unix 
(grep for DBUS_ERROR_NOT_SUPPORTED) so the code calling them already 
handles NOT_SUPPORTED, this is the reason they could just fail at 
runtime and have it be OK.

> At the moment we have the descriptors with something like "home made
> RTTI in C", but this is not a solid solution of the problem, because
> errors will be caught at runtime not compile time.
> 
> For the windows code it would be best to drop the indistinguishably
> of the descriptors and to introduce types for each resource:
> DBusFile, DBusSocket, DBusPipe, then with functions like
> _dbus_open_file, _dbus_open_socket,... errors are caught at
> compile time and we don't need to encode the descriptors with
> the some type information.

Agreed, my other mail I just sent suggested something very similar.

> Is this the right way to handle this or has it no chance
> to go into cvs?

Please, do cleanups like this instead of introducing weird hacks. 
Another example, it's better to add DBusError to functions, instead of 
trying to emulate errno on Windows.

Anytime you're doing crazy emulation hacks on Windows, please just clean 
up the sysdeps API instead. It will be much better for everyone.

Havoc