mingw: pwd.h and grp.h functions, uid_t, getuid, chown, fork, etc

[Simon Josefsson]

Looking at the recent gnulib build failures on mingw, there is a pattern
of remaining issues to work on.  For reference see:

http://autobuild.josefsson.org/gnulib/log-200810220353954696000.txt

Two main problems appears to be:

1) pwd.h user handling functions including chown

Is there any chance to implement a replacement pwd.h or grp.h header
that will be useful on mingw?

As far as I can tell from MSDN documentation, Windows doesn't have any
numeric user identity concept.  I may be wrong though, as I'm not a
Windows programmer.

If I'm correct, most if not all of the pwd.h and grp.h types and
functions becomes impossible to adapt.  See the POSIX documentation:

http://www.opengroup.org/onlinepubs/009695399/basedefs/pwd.h.html
http://www.opengroup.org/onlinepubs/009695399/basedefs/grp.h.html

Maybe we could provide pwd.h and grp.h header files that does something
like:

# undef getuid
# define getuid() \
    (GL_LINK_WARNING ("getuid is not supported under mingw"), \
     getuid ())

It may be possible to provide dummy functions on mingw for some
functions, for example:

int chown (const char *path, uid_t owner, gid_t group)
{
  errno = ENOSYS;
  return -1;
}

This requires defining uid_t and gid_t to some reasonable type though.

I wonder if these kind of replacements are useful, or if they just
worsen the problem?

It can be useful to find out the current user's username though, and
this is possible under Windows (i.e., GetUserName).  In GNU SASL, the
only reason I use pwd.h is to get the user's username.  So it may be
sufficient to provide a wrapper function for this particular purpose
only?  On the other hand, that would result in using non-POSIX interface
to do something for which there is POSIX functions for, which I dislike.

2) fork

This is needed by spawni.c and savewd.c only.

Possibly the spawni.c usage could be ported to Windows, supported on a
best effort basis?

Savewd.c uses fork to achieve something that may be possible to achieve
under Windows using other mechanisms.  It may be possible to port this
code as well.

---

Generally, I think it would be nice to identify all modules that doesn't
work under mingw yet.  Maybe they should even be disabled by default,
when cross-compiled to mingw?

I'll see if I can disable the modules that haven't been ported to mingw
yet during the daily build, to be able to catch link-time problems.  I
suspect this will reveal more problems that should be fixed.

/Simon