dbus-sysdeps-unix.h

[Peter Kümmel]

Havoc Pennington wrote:
> Hi,
> 
> Peter Kümmel wrote:
>> dbus_bool_t _dbus_open_file (DBusFile   *file,
>>                              const char *filename,
>>                              int         oflag,
>>                              int         pmode);
> 
> small thing, if these are bitfields, should be unsigned int.
> 
> Are the flags really used though? this is just an ad hoc internal API,
> so it's fine to have e.g. dbus_create_file_exclusively() that creates,
> and dbus_open_file() that does not create, for example. we could add
> more as required. anyway, why not grep for "open" usages and see if
> there are patterns where only one or two sets of flags are ever used.
> 

Looking at the code again, I see that a public file access
interface isn't necessary, at least when we don't move some
files back to sysdeps.c: Currently all relevant code
are in -win/-unix files.
Maybe dbus_create_file_exclusively() as public function is enough.

> Higher level is better, it makes it easier to implement and keeps us
> from relying on detailed platform semantics.
> 
>> As intermidate step I've renamed _dbus_close to
>> _dbus_close_not_a_file, and fixed the rest of the code.
> 
> Is there a not-a-file other than a socket? I think _dbus_close_socket is
> a bit clearer. (I thought the deal on windows was that there were
> "sockets" and "everything else" rather than "files" and "everything
> else"? but I don't really know)
> 

Mabye sometimes there is a pipe implementation on windows, so
we can prepare for this now. Or is a pipe technically the same
as a socket, I don't know.

>> Should I use this type also for the unix code or
>> is a other way preferred?
> 
> I think just putting the definition of the struct in the -unix.c and in
> -win.c makes sense, and make it the cleanest definition for each
> platform. If they are both just an int, that's fine, but it's not
> important to share a three-line struct definition across platforms. It
> is important to keep any of the outside-sysdeps code from cheating and
> accessing the int directly.
> 
>> And how should I prepare the patch, on patch for all
>> _file, _socket, _pipe renaming?
> 
> The smallest patch that compiles and makes sense is usually best. If you
> wanted you could even separate the renaming (socket/file split) from
> adding the abstraction (DBusFile), though it isn't necessary I don't think.
> 

I try to make the patches as simple as possible.

> Havoc
> 
> 


-- 
Peter Kümmel