gethostname max len

gethostname max len

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

        * posix.c (scm_gethostname): Use sysconf(_SC_HOST_NAME_MAX) and
        MAXHOSTNAMELEN when available.

It's possible MAXHOSTNAMELEN is enough in practice, but posix
specifies HOST_NAME_MAX instead of MAXHOSTNAMELEN, so it seems
worthwhile checking that too.


[-- Attachment #2: posix.c.maxhostname.diff --]
[-- Type: text/plain, Size: 1451 bytes --]

--- posix.c.~1.127.~	2004-03-18 14:02:04.000000000 +1000
+++ posix.c	2004-03-22 08:19:40.000000000 +1000
@@ -114,6 +114,14 @@
 #  include <crypt.h>
 #endif
 
+#ifdef HAVE_NETDB_H
+#include <netdb.h>      /* for MAXHOSTNAMELEN on Solaris */
+#endif
+
+#ifdef HAVE_SYS_PARAM_H
+#include <sys/param.h>  /* for MAXHOSTNAMELEN */
+#endif
+
 #if HAVE_SYS_RESOURCE_H
 #  include <sys/resource.h>
 #endif
@@ -1746,12 +1754,31 @@
 	    "Return the host name of the current processor.")
 #define FUNC_NAME s_scm_gethostname
 {
-  /* 256 is for Solaris, under Linux ENAMETOOLONG is returned if not
-     large enough.  */
-  int len = 256, res, save_errno;
+  int len, res, save_errno;
   char *p = scm_malloc (len);
   SCM name;
 
+  /* Default 256 is for Solaris, under Linux ENAMETOOLONG is returned if not
+     large enough.  */
+  len = 256;
+
+  /* various systems define MAXHOSTNAMELEN (including Solaris in fact) */
+#ifdef MAXHOSTNAMELEN
+  len = MAXHOSTNAMELEN;
+#endif
+
+  /* POSIX specifies the HOST_NAME_MAX system parameter for the max size,
+     which may reflect a particular kernel configuration.
+     Must watch out for this existing but giving -1, as happens for instance
+     in gnu/linux glibc 2.3.2.  */
+#if HAVE_SYSCONF && defined (_SC_HOST_NAME_MAX)
+  {
+    long n = sysconf (_SC_HOST_NAME_MAX);
+    if (n != -1L)
+      len = n;
+  }
+#endif
+
   res = gethostname (p, len);
   while (res == -1 && errno == ENAMETOOLONG)
     {

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gethostname max len

[Kevin Ryde]

Wolfgang Jaehrling <pro-linux@gmx.de> writes:
>
> Which is what Guile probably also should do, otherwise it won't work
> correctly on the GNU system, which has no limit on the length of host
> names;

Oh, is that how the -1 is to be understood?  Nosing around the glibc
sources it looked only like it didn't have an implementation for
HOST_NAME_MAX yet.

> the current code that checks for ENAMETOOLONG looks quite
> GNU/Linux-specific.

Yep.  (I'm not proposing to change that, only to get a better first
size for the buffer.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gethostname max len

[Wolfgang Jaehrling]

On Mon, Mar 22, 2004 at 08:22:52AM +1000, Kevin Ryde wrote:
>         * posix.c (scm_gethostname): Use sysconf(_SC_HOST_NAME_MAX) and
>         MAXHOSTNAMELEN when available.
> 
> It's possible MAXHOSTNAMELEN is enough in practice, but posix
> specifies HOST_NAME_MAX instead of MAXHOSTNAMELEN, so it seems
> worthwhile checking that too.

The Single Unix Specification says about sysconf():

  "If name is an invalid value, sysconf() shall return -1 and set
  errno to indicate the error. If the variable corresponding to name
  has no limit, sysconf() shall return -1 without changing the value
  of errno."

And in the following informative section:

  "As -1 is a permissible return value in a successful situation, an
  application wishing to check for error situations should set errno
  to 0, then call sysconf(), and, if it returns -1, check to see if
  errno is non-zero."

Which is what Guile probably also should do, otherwise it won't work
correctly on the GNU system, which has no limit on the length of host
names; the current code that checks for ENAMETOOLONG looks quite
GNU/Linux-specific.

Cheers,
Wolfgang

-- 
Repeating false statements makes them true.
Repeating false statements makes them true.
Repeating false statements makes them true.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gethostname max len

[Wolfgang Jaehrling]

On Mon, Mar 22, 2004 at 11:02:55AM +1000, Kevin Ryde wrote:
> Wolfgang Jaehrling <pro-linux@gmx.de> writes:
> > Which is what Guile probably also should do, otherwise it won't work
> > correctly on the GNU system, which has no limit on the length of host
> > names;
> 
> Oh, is that how the -1 is to be understood?  Nosing around the glibc
> sources it looked only like it didn't have an implementation for
> HOST_NAME_MAX yet.

The GNU system deliberately defines no such limits, following the
spirit of the GNU coding standards, which say (node "Semantics"):

  "Avoid arbitrary limits on the length of _any_ data structure,
  including file names, lines, files, and symbols, by allocating all
  data structures dynamically.  In most Unix utilities, "long lines
  are silently truncated."  This is not acceptable in a GNU utility."

I'm personally quite happy if programs at least try to use constants
like PATH_MAX, so that we can find these places and fix them.  I
really don't want to know how many programs just use arrays of size
1024 for file names.  There are even manual pages out there (like
realpath(3) on my GNU/Linux system) that contain examples like:

  #ifdef PATH_MAX
    path_max = PATH_MAX;
  #else
    path_max = pathconf (path, _PC_PATH_MAX);
    if (path_max <= 0)
      path_max = 4096;
  #endif

which tries to do the right thing, but ends up doing nonsense on the
GNU system (as pathconf() behaves like sysconf(), returning -1 to
indicate the absence of any limit).  Though I have to admit that doing
the right thing in a portable way is probably more work than it should
be.  But that's what you get for using C instead of Scheme. :-)

Cheers,
Wolfgang

-- 
Repeating false statements makes them true.
Repeating false statements makes them true.
Repeating false statements makes them true.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gethostname max len

[Nelson H. F. Beebe]

Discussions on this list earlier this week debated how to handle the
return from gethostname(), which might produce a string of
platform-dependent size.

One correspondent suggested using PATH_MAX.

This is, I believe, unwise, for at least these reasons:

(1) There has been great historic variability in the name of the
    parameter that holds the size of the longest possible path; see
    below. 

(2) The ISO Standard C name for that parameter is not PATH_MAX, but
    this one (from section 7.19.1 of the 1999 Standard):

>> ...
>> 		FILENAME_MAX
>> 
>>      which expands to an integer constant expression that is the size
>>      needed for an array of char large enough to hold the longest file
>>      name string that the implementation
>> ...

(3) More seriously, that limit is not O/S or compiler dependent, but
    rather, filesystem dependent.  A Unix system might support
    4096-character paths in its own filesystem, then mount a PC DOS
    system with 8+3 limits on filenames, and a 128-character limit on
    the path.

The proper way to handle this is via the POSIX (IEEE Std 1003.1-2001)
pathconf() and fpathconf() library calls:

	#include <unistd.h>	/* POSIX header file */

	long int n;

	n = pathconf("/path/to/file", _PC_PATH_MAX);
	n = fpathconf(fileno(stdin),  _PC_PATH_MAX);

Only if these routines, their header file, and the symbol
_PC_PATH_MAX, are not available (as determined by GNU autoconf),
should code fall back to using FILENAME_MAX, and then further caution
must be applied, because HP-UX 10 and 11 define this in <stdio.h> with
the value 14, far below the value of 1024 that their filesystems
support.

The following tests show that the return values from the POSIX
functions also need to be checked carefully:

% cat pathconf.c
/***********************************************************************
[26-Mar-2004]
***********************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void
show_fpathconf(int fd)
{
    printf("fpathconf(): maximum path for file descriptor %d\t:\t%7ld\n", fd, (long)fpathconf(fd, _PC_PATH_MAX));
}

void
show_pathconf(const char *s)
{
    printf("pathconf(): maximum path in %-15s\t:\t%7ld\n", s, (long)pathconf(s, _PC_PATH_MAX));
}

int
main(void)
{
    printf("FILENAME_MAX\t\t\t\t\t:\t%7d\n", FILENAME_MAX);

    show_pathconf("/");
    show_pathconf("/tmp");
    show_pathconf("/var/tmp");
    show_pathconf("./");
    show_fpathconf(fileno(stdin));
    show_fpathconf(fileno(stdout));
    show_fpathconf(fileno(stderr));

    return (EXIT_SUCCESS);
}

The following experiments illustrate some of the variations to be
found; return values of -1 mean that the value is indeterminate (so
the caller must be prepared to handle a dynamically-sized string):

On HP-UX 11.11 PA-RISC 8700:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :            14
	pathconf(): maximum path in /                   :          1023
	pathconf(): maximum path in /tmp                :          1023
	pathconf(): maximum path in /var/tmp            :          1023
	pathconf(): maximum path in ./                  :          1024
	fpathconf(): maximum path for file descriptor 0 :            -1
	fpathconf(): maximum path for file descriptor 1 :            -1
	fpathconf(): maximum path for file descriptor 2 :            -1

On FreeBSD 5.1 Alpha:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :          1024
	pathconf(): maximum path in /                   :          1024
	pathconf(): maximum path in /tmp                :          1024
	pathconf(): maximum path in /var/tmp            :          1024
	pathconf(): maximum path in ./                  :            -1
	fpathconf(): maximum path for file descriptor 0 :          1024
	fpathconf(): maximum path for file descriptor 1 :          1024
	fpathconf(): maximum path for file descriptor 2 :          1024

On GNU/Linux IA-64:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :          4096
	pathconf(): maximum path in /                   :          4096
	pathconf(): maximum path in /tmp                :          4096
	pathconf(): maximum path in /var/tmp            :          4096
	pathconf(): maximum path in ./                  :          4096
	fpathconf(): maximum path for file descriptor 0 :          4096
	fpathconf(): maximum path for file descriptor 1 :          4096
	fpathconf(): maximum path for file descriptor 2 :          4096

On SGI IRIX MIPS and Solaris 9 SPARC:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :          1024
	pathconf(): maximum path in /                   :          1024
	pathconf(): maximum path in /tmp                :          1024
	pathconf(): maximum path in /var/tmp            :          1024
	pathconf(): maximum path in ./                  :          1024
	fpathconf(): maximum path for file descriptor 0 :          1024
	fpathconf(): maximum path for file descriptor 1 :          1024
	fpathconf(): maximum path for file descriptor 2 :          1024

On Compaq/DEC Alpha OSF/1 4.0 and 5.1:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :           255
	pathconf(): maximum path in /                   :          1023
	pathconf(): maximum path in /tmp                :          1023
	pathconf(): maximum path in /var/tmp            :          1023
	pathconf(): maximum path in ./                  :          1024
	fpathconf(): maximum path for file descriptor 0 :            -1
	fpathconf(): maximum path for file descriptor 1 :            -1
	fpathconf(): maximum path for file descriptor 2 :            -1

On IBM RS/6000 AIX 4.2:
	cc pathconf.c && ./a.out
	FILENAME_MAX                                    :           255
	pathconf(): maximum path in /                   :          1023
	pathconf(): maximum path in /tmp                :          1023
	pathconf(): maximum path in /var/tmp            :          1023
	pathconf(): maximum path in ./                  :          1024
	fpathconf(): maximum path for file descriptor 0 :          1023
	fpathconf(): maximum path for file descriptor 1 :          1023
	fpathconf(): maximum path for file descriptor 2 :          1023

Here is a snippet from my own code that notes the historical
variation:

--------	-------------	------------------------------------------
Name		Definition	System
--------	-------------	------------------------------------------
FNMAX		<stdio.h>	PCC-20
MAXPATH		<dir.h>		Turbo C 2.0, C and C++ 3.0, and TopSpeed C
_MAX_PATH	<stdlib.h>	Microsoft C 5.0, 6.0, 7.0 and TopSpeed C
MAX_PATHLEN	<sys/param.h>	Sun OS (4.2BSD), 4.3BSD, Gould UTX/32,
				HPUX, KCC-20, AIX (RT, RS, PS/2, 370),
				HP/Apollo DomainOS, DEC Alpha (OSF/1)
PATH_MAX	<stdio.h>	SYS V (Silicon Graphics)
PATH_MAX	<limits.h>	POSIX, DEC Alpha (OSF/1)
FILENAME_MAX	<stdio.h>	Intel RMX, NeXT Mach, Turbo C/C++ 3.0,
				Standard C
--------	-------------	------------------------------------------

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gethostname max len

[Kevin Ryde]

"Nelson H. F. Beebe" <beebe@math.utah.edu> writes:
>
> One correspondent suggested using PATH_MAX.

Not quite, I think the topic drifted.  PATH_MAX is of course unrelated
to gethostname.

> (1) There has been great historic variability in the name of the
>     parameter that holds the size of the longest possible path; see
>     below. 

I don't think there's many places depending on path length.  getcwd
for instance has a malloc strategy.

The readdir_r I'm proposing will depend on NAME_MAX, but it follows
what the glibc manual says, so it can't be all bad.

The alternative to readdir_r is a mutex to protect the DIR.  A single
global mutex might hurt parallelism though, if readdir goes away for a
longish time talking NFS or whatever.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel