bug-gnulib
[Top][All Lists]
Advanced

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

Re: HOST_NAME_MAX


From: Bruno Haible
Subject: Re: HOST_NAME_MAX
Date: Sat, 8 Aug 2009 11:20:47 +0200
User-agent: KMail/1.9.9

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.

> 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.

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...).

I'm committing this:


2009-08-08  Bruno Haible  <address@hidden>

        * m4/gethostname.m4 (gl_FUNC_GETHOSTNAME): Define HOST_NAME_MAX also
        for the various Unix platforms.
        * doc/posix-headers/limits.texi: Update platforms list regarding
        HOST_NAME_MAX.
        Reported by Tom G. Christensen <address@hidden>.

*** m4/gethostname.m4.orig      2009-08-08 11:15:02.000000000 +0200
--- m4/gethostname.m4   2009-08-08 11:09:52.000000000 +0200
***************
*** 1,4 ****
! # gethostname.m4 serial 7
  dnl Copyright (C) 2002, 2008, 2009 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # gethostname.m4 serial 8
  dnl Copyright (C) 2002, 2008, 2009 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***************
*** 43,54 ****
    fi
  
    dnl Also provide HOST_NAME_MAX when <limits.h> lacks it.
!   if test "$gl_cv_w32_gethostname" = "yes"; then
!     # <http://msdn.microsoft.com/en-us/library/ms738527.aspx> says:
!     # "if a buffer of 256 bytes is passed in the name parameter and
!     # the namelen parameter is set to 256, the buffer size will always
!     # be adequate."
!     AC_DEFINE([HOST_NAME_MAX], [256],
        [Define HOST_NAME_MAX when <limits.h> does not define it.])
    fi
  ])
--- 43,94 ----
    fi
  
    dnl Also provide HOST_NAME_MAX when <limits.h> lacks it.
!   dnl - On most Unix systems, use MAXHOSTNAMELEN from <sys/param.h> instead.
!   dnl - On Solaris, Cygwin, BeOS, use MAXHOSTNAMELEN from <netdb.h> instead.
!   dnl - On mingw, use 256, because
!   dnl   <http://msdn.microsoft.com/en-us/library/ms738527.aspx> says:
!   dnl   "if a buffer of 256 bytes is passed in the name parameter and
!   dnl    the namelen parameter is set to 256, the buffer size will always
!   dnl    be adequate."
!   dnl With this, there is no need to use sysconf (_SC_HOST_NAME_MAX), which
!   dnl is not a compile-time constant.
!   dnl We cannot override <limits.h> using the usual technique, because
!   dnl gl_CHECK_NEXT_HEADERS does not work for <limits.h>. Therefore retrieve
!   dnl the value of HOST_NAME_MAX at configure time.
!   AC_CHECK_HEADERS_ONCE([sys/param.h])
!   AC_CHECK_HEADERS_ONCE([sys/socket.h])
!   AC_CHECK_HEADERS_ONCE([netdb.h])
!   AC_CACHE_CHECK([for HOST_NAME_MAX], [gl_cv_decl_HOST_NAME_MAX], [
!     gl_cv_decl_HOST_NAME_MAX=
!     AC_EGREP_CPP([lucky], [
! #include <limits.h>
! #ifdef HOST_NAME_MAX
! lucky
! #endif
!       ], [gl_cv_decl_HOST_NAME_MAX=yes])
!     if test -z "$gl_cv_decl_HOST_NAME_MAX"; then
!       dnl It's not defined in <limits.h>. Substitute it.
!       if test "$gl_cv_w32_gethostname" = yes; then
!         dnl mingw.
!         gl_cv_decl_HOST_NAME_MAX=256
!       else
!         _AC_COMPUTE_INT([MAXHOSTNAMELEN], [gl_cv_decl_HOST_NAME_MAX], [
! #include <sys/types.h>
! #if HAVE_SYS_PARAM_H
! # include <sys/param.h>
! #endif
! #if HAVE_SYS_SOCKET_H
! # include <sys/socket.h>
! #endif
! #if HAVE_NETDB_H
! # include <netdb.h>
! #endif
! ])
!       fi
!     fi
!   ])
!   if test "$gl_cv_decl_HOST_NAME_MAX" != yes; then
!     AC_DEFINE_UNQUOTED([HOST_NAME_MAX], [$gl_cv_decl_HOST_NAME_MAX],
        [Define HOST_NAME_MAX when <limits.h> does not define it.])
    fi
  ])
*** doc/posix-headers/limits.texi.orig  2009-08-08 11:15:02.000000000 +0200
--- doc/posix-headers/limits.texi       2009-08-08 10:37:44.000000000 +0200
***************
*** 8,14 ****
  Portability problems fixed by Gnulib:
  @itemize
  The @code{HOST_NAME_MAX} macro is not defined on some platforms:
! mingw.
  @end itemize
  
  Portability problems not fixed by Gnulib:
--- 8,14 ----
  Portability problems fixed by Gnulib:
  @itemize
  The @code{HOST_NAME_MAX} macro is not defined on some platforms:
! 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, Solaris 10, Cygwin, mingw, Interix 3.5, BeOS.
  @end itemize
  
  Portability problems not fixed by Gnulib:




reply via email to

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