bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: declare gethostname in unistd.h


From: Simon Josefsson
Subject: Re: declare gethostname in unistd.h
Date: Mon, 20 Oct 2008 12:05:11 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Hi Simon,
>
> Here's a proposed patch so that on platforms where gethostname() is missing
> and substituted by gnulib, it is declared in <unistd.h>. OK to commit?

Hi.  Yes, please do.

> Note that this does not resolve the issue with mingw. On mingw, <winsock2.h>
> declares gethostname() also - but it requires linking with -lws2_32,
> right?

Yes.

Win32 also has GetComputerName that does not need -lws2_32.  It would be
easier to use, but which one is right semantically I don't know.

> How should the gnulib module handle this?
> 1. Should gnulib's replacement call the winsock2 gethostname()?

I think so.  The Win32 gethostname function takes 'char*,int' so it
needs to be wrapped by gnulib, because the POSIX signature is
'char*,size_t'.

> 2. Should this be done through immediate linking, or dynamic linking?

getaddrinfo.m4 adds -lws2_32 to LIBS automatically now.

A tangent:

  It may be cleaner to define a MINGW_LIBS variable instead, and ask
  developers to add $(MINGW_LIBS) to automake LIBADD variables for
  executables that need it.  sockets.m4 has been fixed in this way
  already.

  Possibly the -lws2_32/LIBSOCKET/MINGW_LIBS handling should be put in a
  separate module?  Then getaddrinfo and sockets can depend on it,
  rather than duplicating it.

gethostname.c could also use GetModuleHandle, similar to how
getaddrinfo.c works, to avoid the -lws2_32 requirement.  If the
application would not otherwise link to -lws2_32 this approach may be
nicer.  But if applications are linked to -lws2_32 because of other
gnulib modules anyway, it doesn't make much sense.

The GetModuleHandle approach, together with a fallback replacement
function, results in better portability generally.  Some Windows
releases does not have getaddrinfo, and if the application is linked
against -lws2_32 that has it, and the binary is transferred to an old
system, it won't work.  I suspect all relevant Windows releases has
gethostname though.

Actually, the getaddrinfo module supports both variants: if the
applications sets an appropriate WINVER variable, getaddrinfo will
detect as being in -lws2_32 by configure, and the replacement code will
not be used.  By default, it will not be detected as being in -lws2_32,
and the replacement will be used (which tries GetModuleHandle first).

Maybe the same approach cannot be used for gethostname: the signatures
are different, so if the application passes a size_t and the function
assumes int, it may break on platforms where int is 32 bit and size_t is
64 bit (if there are any such Windows platforms?).  A wrapper function
is needed to convert the data types.  Or maybe a #define with a cast?

I'm not sure.  It seems pretty clear that MINGW_LIBS and GetModuleHandle
are two approaches that can solve this problem.  The GetModuleHandle
solution is more complex, but I'm leaning slightly towards it because it
should in theory result in better portability.  OTOH, complexity can
lead to less portability in practice.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]