home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!not-for-mail
- From: karish@pangea.Stanford.EDU (Chuck Karish)
- Newsgroups: comp.std.unix
- Subject: Re; PATH_MAX
- Date: 23 Dec 1992 13:28:40 -0800
- Organization: Mindcraft, Inc.
- Lines: 36
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <1halm8INN9c6@ftp.UU.NET>
- References: <1gs9qaINN9rl@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
-
- In article <1gs9qaINN9rl@ftp.UU.NET> eric@mks.com (Eric Gisin) writes:
- >On a system with a defined, constant value for PATH_MAX,
- >what would pathconf("/tmp", _PC_PATH_MAX) return?
- >The books I have, Zlotnick and O'Reilly, say PATH_MAX-4.
- >The systems I have say PATH_MAX.
- >Who is right? If it is PATH_MAX-4, how would fpathconf work?
-
- POSIX.1-1990 says, in note (5) to Table 5-2 (5.7.1.3):
-
- If path or fildes refers to a directory, the value
- returned is the maximum length of a relative pathname
- when the specified directory is the working directory.
-
- However, the description of the values in Table 2-6,
- which includes PATH_MAX, (2.8.5) says:
-
- The values in Table 2-6 may be constants within an
- implementation or may vary from one pathname to
- another.
-
- The implementation described above chooses to have
- {PATH_MAX} constant rather than variable according to
- the length of the path prefix. This is legitimate.
-
- Another interesting question is whether the fixed value
- of PATH_MAX accurately reflects the capabilities of
- the filesystem.
- --
-
- Chuck Karish karish@mindcraft.com
- (415) 323-9000 x117 karish@pangea.stanford.edu
-
-
- Volume-Number: Volume 29, Number 83
-