Re: HOST_NAME_MAX

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Right, it seems clear that gnulib should define HOST_NAME_MAX on more
>> systems.
>> 
>> I note that a Solaris 10 I have access to defines _POSIX_HOST_NAME_MAX:
>> 
>> /usr/include/limits.h:#define   _POSIX_HOST_NAME_MAX                    255
>
> But _POSIX_HOST_NAME_MAX is only the minimum value that HOST_NAME_MAX can
> ever have, per the standard. See
> <http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html>
> Therefore you cannot allocate an array of size _POSIX_HOST_NAME_MAX,
> invoke gethostname() and expect that the result will fit. It's like
> allocating an array of size 3 and calling getcwd() - often the result
> will not fit.

Right.

>> But I can't find HOST_NAME_MAX.  Indeed MAXHOSTNAMELEN exists:
>> 
>> /usr/include/netdb.h:#define    MAXHOSTNAMELEN  256
>
> Indeed, MAXHOSTNAMELEN has the same semantics as HOST_NAME_MAX.
> So we can use the value
>   - MAXHOSTNAMELEN from <sys/param.h>
>     on MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, AIX 5.1, HP-UX 11,
>        IRIX 6.5, OSF/1 5.1, Interix 3.5, Haiku,
>   - MAXHOSTNAMELEN from <netdb.h>
>     on Solaris 10, Cygwin, BeOS,
>   - 256 on mingw.

Ok.

> FreeBSD does not define HOST_NAME_MAX on purpose. They have a comment saying
> that they want to force applications to call sysconf(_SC_HOST_NAME_MAX).
> But they still define MAXHOSTNAMELEN, so there is no real point is writing
> code for hostnames of potentially unbounded size (calling gethostname
> repeatedly, with buffers of growing size...).

Is the maximum string ever returned by gethostname bounded by
MAXHOSTNAMELEN?

It seems clear that FreeBSD isn't POSIX compliant here since
HOST_NAME_MAX needs to be provided, as far as I can tell.  So gnulib
should fix that.  If hostnames cannot ever be larger than MAXHOSTNAMELEN
on FreeBSD, I agree we should use that as the value.

I guess looking into FreeBSD libc would answer this.

> I'm committing this:

Thanks, if it breaks I'll report back.

/Simon