dbus-sysdeps-unix.h

[Peter Kümmel]

Havoc Pennington wrote:
>> 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.

Ah, I didn't know that. So we should also not test for headers in
other files.

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

So we have two system-header headers and one interface header.

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

The hacks are there only because we wanna have a running system which we
could change step by step.

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

Good to know that such changes are acceptable.

> Havoc
> 
> 


-- 
Peter Kümmel