For masochists: the leap o faith

Robert Collins
Fri Nov 14 22:48:00 GMT 2003

Christopher Faylor wrote:

> On Sat, Nov 15, 2003 at 07:31:42AM +1100, Robert Collins wrote:
>>Robert Collins wrote:
>>>Ok, so this it for tonight, my bed is calling me.

>>As far as applications maing assumptions, unix file systems don't 
>>guarantee PATH_MAX: thats an upper limit of the OS, applications are 
>>expected to be able to handle to up to PATH_MAX... but can't expect the 
>>OS to do so in every case.
> It is fairly unusual for PATH_MAX to be many times greater than what
> is support by pathconf.

And yet:

the notes allude to the issue: unless you call [f]pathconf with a path 
for details on, some implementations won't supply valid information.

You're right though, that we need to update [f]pathconf as part of this.

If the implementation needs to use path to determine the value of name 
and the implementation does not support the association of name with the 
file specified by path, or if the process did not have appropriate 
privileges to query the file specified by path, or path does not exist, 
pathconf() returns -1 and errno is set to indicate the error.

and in
we have " Pathname Variable Values

The values in the following list may be constants within an 
implementation or may vary from one pathname to another. For example, 
file systems or directories may have different characteristics.

A definition of one of the values will be omitted from the <limits.h> 
header on specific implementations where the corresponding value is 
equal to or greater than the stated minimum, but where the value can 
vary depending on the file to which it is applied. The actual value 
supported for a specific pathname will be provided by the pathconf() 
function. "

I think we need to remove the PATH_MAX constant as per their comment, as 
we will now offer runtime differences:

NAME_MAX will still be constant, (although I haven't reviewed msdn on 
that yet).


More information about the Cygwin-patches mailing list