Simon Josefsson <[EMAIL PROTECTED]> wrote:
> I have done a quick port of Shishi to MinGW and noticed some things that
> were needed but for which there were no gnulib replacements:
>
> getuid
> getpwnam
> syslog
> struct passwd from pwd.h
> res_query from arpa/nameserv.h and -lresolv
> C_IN, T_TXT, T_SRV etc from arpa/nameserv.h
> netinet/in6.h
> resolv.h
> gethostname prototype from unistd.h
> h_errno? from netdb.h
> sys/ioctl.h
> errno.h
>
> Some of them may not be well standardized..
>
> I suspect some of these are candidates to be implemented in gnulib.
> However, the implementation will be very trivial, because Windows
> doesn't have a similar concept.  For example, for 'getuid', the MinGW
> code in gnulib for it would just return 0, 42, or whatever.
>
> I've noticed that kdewin32 implements some of these, but most of the
> functions (including getuid) are just dummy functions:
>
> http://websvn.kde.org/trunk/kdesupport/kdewin32/include/mingw/
> http://websvn.kde.org/trunk/kdesupport/kdewin32/src/
> http://websvn.kde.org/trunk/kdesupport/kdewin32/src/unistd.c?revision=696032&view=markup
>
> What do people think about having dummy functions in gnulib?  Do they
> serve a purpose, or do they hide problems and lead to confusion?

At least in some cases, I think they're essential to "clean" code.
For example, I've been using a couple of SELinux-related modules
in coreutils/gl/ so that I can do this without #ifdefs:

  #include <selinux/selinux.h>

as well as use all of the required functions even when they're
not supported.  The stubs always fail with an error code implying
SELinux is not supported, and the code deals with that.  IMHO, that is
far better than littering the code with cpp conditionals like #ifdef
HAVE_EACH_INDIVIDUAL_SELINUX_FUNCTION or #ifdef USE_SELINUX


Reply via email to