From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: beebe@math.utah.edu
Subject: Re: gethostname max len
Date: Fri, 26 Mar 2004 07:47:42 -0700 (MST) [thread overview]
Message-ID: <CMM.0.92.0.1080312462.beebe@psi.math.utah.edu> (raw)
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
next reply other threads:[~2004-03-26 14:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-26 14:47 Nelson H. F. Beebe [this message]
2004-03-27 22:48 ` gethostname max len Kevin Ryde
-- strict thread matches above, loose matches on Subject: below --
2004-03-21 22:22 Kevin Ryde
2004-03-22 1:05 ` Wolfgang Jaehrling
2004-03-22 1:02 ` Kevin Ryde
2004-03-22 1:34 ` Wolfgang Jaehrling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CMM.0.92.0.1080312462.beebe@psi.math.utah.edu \
--to=beebe@math.utah.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).