Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!uunet!usenix!std-unix
From: donn@hpfcdc.uucp (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Meaning of _PC_PATH_MAX
Message-ID: <482@usenix.ORG>
Date: 31 Aug 90 23:44:44 GMT
References: <465@usenix.ORG>
Sender: std-unix@usenix.ORG
Lines: 38
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

From:  Donn Terry <donn@hpfcdc.uucp>

>IEEE Std 1003.1-1988 paragraph 5.7.1.2 note 5 describes the value 
>returned by pathconf() when _PC_PATH_MAX is used as an argument as, 
>"The maximum length of a relative pathname when the specified 
>directory is the working directory."

>I have tried this on several POSIX.1 systems.  None of them seem to 
>enforce the maximum.  In fact they all return a constant (say, 1024) 
>even if the path given to pathconf() is already longer than that.

>Is this conforming behavior?

>If it is conforming, how should a portable application determine the 
>longest pathname a user can specify?  

This is hard to get a clear reading on from what you have written.  It
could either be sloppy implementation or perfectly conformant.

POSIX specifically permits (in shell notation):
	cd /
	cd <1024 character pathname>
	cd <another such thing>
	...

There is no longest pathname a user can specify; there is a longest
one from / and from the current working directory.  Pathconf doesn't
worry about what the cwd is.

>What about _PC_NAME_MAX?  May readdir() return a longer name than the 
>value returned by pathconf() for that directory?

It shouldn't.  No location relative issues here.

Donn Terry
(As usual... speaking only for myself.)

Volume-Number: Volume 21, Number 79