Re: gethostname

[Simon Josefsson]

Sam Steingold <address@hidden> writes:

>>> 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead?
>>>
>>> 2. are there really systems without uname & <sys/utsname.h>, given
>>> that these are in posix?
>>> http://www.opengroup.org/onlinepubs/009695399/functions/uname.html
>>
>> I think the right solution here should be to apply the patch below.
>> If there are problems on any system caused by that, the solution to
>> that problem should be to create a module for sys/utsname.h and uname.
>> The gethostname module shouldn't depend on such modules, they need to
>> be added manually by maintainers who want compatibility with non-POSIX
>> systems.  Thoughts?
>
> note that gethostname is just as posix as uname,
> http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html
> so the gethostname module is only needed for non-posix systems.

Indeed, so I am less sure my patch is the right thing.  Could you
explain why the current code causes problems for you?

>> 2. are there really systems without uname & <sys/utsname.h>, given that 
>> these 
>> are in posix? 
>> http://www.opengroup.org/onlinepubs/009695399/functions/uname.html
>
> Yes, some old systems did not have uname() and <sys/utsname.h>: especially
> SunOS 4. But these are not porting targets today any more.

Didn't SunOS 4 have gethostname?

> Simon Josefsson wrote:
>> I think the right solution here should be to apply the patch below.  If
>> there are problems on any system caused by that, the solution to that
>> problem should be to create a module for sys/utsname.h and uname.
>
> The gnulib docs (doc/posix-functions/{gethostname,uname}.texi) say that
> uname and gethostname are both missing on mingw systems. If your patch
> is applied in the current state, it causes a link error on mingw.
>
> Feel free to contribute an uname() substitute, however. With that in place,
> your patch can be applied without damage.

I'm not sure the patch makes sense any more -- if the gethostname module
is there only to make things work under mingw, my patch would break
things and requires maintainers to manually also add the uname module to
the mix.  How could that dependency be explained?  Having the
gethostname module depend on a uname module would be the wrong approach,
wouldn't it?  Otherwise, all POSIX-replacement modules in gnulib would
need to depend on modules for all POSIX features they use in its
implementation -- I suspect this can quickly become a clique, causing
any addition of a POSIX replacement function to drag in all POSIX
replacement functions in gnulib.

If there were a platform that has uname but doesn't have gethostname, I
can see some merit to my patch, but are there such beasts?

>> The gethostname module shouldn't depend on such modules, they need to be
>> added manually by maintainers who want compatibility with non-POSIX
>> systems.
>
> mingw portability is requested quite often, therefore gnulib includes the
> dependencies needed for mingw portability. We omit dependencies only for
> extremely old systems (e.g. BSD 4.2 - missing memcpy()).

Agreed.

/Simon