Does ANSI C have something like PATHMAX or MAX_PATH?

[Alan Balmer]

Then, that implementation is arguably broken. The specification of the
FILENAME_MAX macro is quite clear:

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 guarantees can be opened;
222)
____________________

222) If the implementation imposes no practical limit on the
length of file name strings, the value of FILENAME_MAX
should instead be the recommended size of an array intended
to hold a file name string. Of course, file name string
contents are subject to other system-specific constraints;
therefore all possible strings of length FILENAME_MAX cannot
be expected to be opened successfully.

Yes, it is quite clear, but HP-UX's value is correct, not "broken."
Here's a statement from Dennis Handly at HP:

"The manifest constant FILENAME_MAX is correctly defined in HP-UX. It
represents the largest value that an application can use and still be
guaranteed it will not cause an error return no matter upon which
HP-UX filesystem the application is attempting to open the file. This
is one of those peculiar maximum-minimum constants defined in the
standards. It is a minimum value which defines a maximum limit that an
application can use under all circumstances."

Note that HP-UX supports some rather old filesystems. On systems which
support POSIX, there are POSIX standards regarding both file name
length and path length. In general, though, the best *guarantee* that
can be made is 14.

Note that the C standard is blind to the concept of path, therefore
the path is implicitly part of the file name.

No. The C standard is blind to the concept of directory structure,
therefore the implication is that files are always opened in the
current directory. No paths are needed.

 

[Dan Pop]

Yes, it is quite clear, but HP-UX's value is correct, not "broken."
Here's a statement from Dennis Handly at HP:

"The manifest constant FILENAME_MAX is correctly defined in HP-UX. It
represents the largest value that an application can use and still be
guaranteed it will not cause an error return no matter upon which
HP-UX filesystem the application is attempting to open the file. This
is one of those peculiar maximum-minimum constants defined in the
standards. It is a minimum value which defines a maximum limit that an
application can use under all circumstances."

Note that HP-UX supports some rather old filesystems. On systems which
support POSIX, there are POSIX standards regarding both file name
length and path length. In general, though, the best *guarantee* that
can be made is 14.

That's bullshit. Read the footnote carefully. If there is a single file
name greater than 13 characters (FILENAME_MAX includes the terminating
null character) that HP-UX *can* open, the value of 14 is incorrect.
The standard only guarantees that *one* filename of FILENAME_MAX - 1
characters can be opened.

And if HP-UX doesn't impose any maximum limit (see the first sentence of
the footnote), it certainly does its users a disservice by recommending
14 as the size of a character array containing valid file names.

No. The C standard is blind to the concept of directory structure,
therefore the implication is that files are always opened in the
current directory. No paths are needed.

Huh?!? Where does the standard define the concept of "current directory"?
The contents of a file name is *entirely* implementation defined and last
time I checked "/usr/bin/X11/xterm" was a valid file name for fopen()
on HP-UX, therefore the HP-UX definition of FILENAME_MAX is utterly
broken (or extremely user unfriendly, if the implementation imposes no
actual limit, but this is not what the HP person was saying).

Dan

 

[Alan Balmer]

That's bullshit. Read the footnote carefully. If there is a single file
name greater than 13 characters (FILENAME_MAX includes the terminating
null character) that HP-UX *can* open, the value of 14 is incorrect.
The standard only guarantees that *one* filename of FILENAME_MAX - 1
characters can be opened.

So, you think they should set it to the maximum supported by any
system they can compile for, whether or not any other system can
support it? OK, have it your way.

And if HP-UX doesn't impose any maximum limit (see the first sentence of
the footnote), it certainly does its users a disservice by recommending
14 as the size of a character array containing valid file names.


Huh?!? Where does the standard define the concept of "current directory"?
The contents of a file name is *entirely* implementation defined and last
time I checked "/usr/bin/X11/xterm" was a valid file name for fopen()
on HP-UX,

Check again. At least some HP-UX documentation treats file names and
path names as different things. And the standard defines the concept
of "current directory" in the same place that it defines path names
and says they're part of the file name. My statement was TIC, intended
to illustrate that your syllogism was just as bogus.

But, have it your way - I don't need another round of "I'm right, you
bullshit."

 

[Dan Pop]

So, you think they should set it to the maximum supported by any
system they can compile for, whether or not any other system can
support it? OK, have it your way.

It's what the standard says they should do, not what I think.

Check again. At least some HP-UX documentation treats file names and
path names as different things.

The HP-UX documentation is irrelevant in a discussion about the C
standard. According to the C standard, in the following call

fopen("/usr/bin/X11/xterm", "r")

"/usr/bin/X11/xterm" is a file name:

7.19.5.3 The fopen function

Synopsis

1 #include <stdio.h>
FILE *fopen(const char * restrict filename,
const char * restrict mode);

Description

2 The fopen function opens the file whose name is the string
pointed to by filename, and associates a stream with it.

If my example fopen call is supposed to be OK under HP-UX, then it is
obvious that defining FILENAME_MAX as 14 is against the requirements of
the standard. The HP-UX implementation has no business defining
FILENAME_MAX according to *another* definition of "file name" than that
used by the C standard. I thought that even you could understand that...

The purpose of FILENAME_MAX in the C standard should be obvious to any C
programmer: if you need to store a file name in a character array,
FILENAME_MAX is the recommended size for the array. It should be
equally obvious that the HP-UX definition of FILENAME_MAX doesn't serve
this purpose. The *only* thing it achieves is breaking correct C code
when ported to HP-UX.

For comparison, Linux headers define it as 4096 and Solaris headers as
1024.

Dan