syntheticpp at gmx.net
Sun Sep 10 12:59:48 PDT 2006
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
> 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.
More information about the dbus