Win32 port

[Havoc Pennington]

Hi,

Tor Lillqvist wrote:
> Peter Kümmel writes:
>  > #ifndef _WIN32
>  > typedef unsigned long dbus_pid_t;
>  > typedef unsigned long dbus_uid_t;
>  > #else
>  > typedef const char *dbus_uid_t;
>  > typedef const char *dbus_gid_t;
>  > #endif
> 
> Has anybody come up with any better idea? The idea behind the above,
> if I recall correctly, is to use the unique string representation of
> SIDs as the gbus_uid and gid type on Win32, and then compare dbus_uids
> and gids with strcmp(). Another possibility would obviouosly be to
> come up with a way to allocate fresh integers for each different SID
> that comes along (and store the mapping somewhere so that different
> processes share the mapping, and so that it is persistent). That would
> presumably be more complex, though.
> 

I would do it like this:

in .h:

typedef struct DBusUID DBusUID;
void dbus_uid_init_unix(DBusUID *uid, unsigned long value);
void dbus_uid_init_win32(DBusUID *uid, const char *str);
dbus_bool_t dbus_uid_equal(const DBusUID *uid1, const DBusUID *uid2);
... etc., include other operations on uid

in .c:

struct DBusUID
{
#ifdef _WIN32
char *uid;
#else
unsigned long uid;
#endif
}

You see the idea, make it a real opaque type. I'm not trying to comment 
on details with the above; e.g. I would imagine the windows uid string 
needs copying and thus init_win32 can fail on OOM and a free operation 
is required? Also I don't remember the dbus convention for naming _equal 
functions, and the functions need a "_" in front, etc.

(Though one detail, I would definitely prefer "ifdef _WIN32" to "ifndef 
_WIN32)

The non-opaque approach, aside from being ugly, will make it very easy 
for people to write code that works on Windows but not UNIX and vice versa.

The above is also what I was trying to suggest for file descriptor 
handling, rather than having a magic integer where on Windows we know 
whether it's a socket or handle by context, make it genuinely opaque and 
typesafe so that only the implementation of the file/socket datatype 
contains ifdefs. Then unportable code simply won't compile or can at 
least be made to fail at runtime.

Havoc