Max Path [Newbie]

[Rookie]

I was just wondering whether there is any MAX_PATH macro in C\C++? If not
what is a safe value to assume for maximum path length?

 

[Jack Klein]

I was just wondering whether there is any MAX_PATH macro in C\C++? If not
what is a safe value to assume for maximum path length?

The macro FILENAME_MAX is defined in <stdio.h>.

 

[Choe]

MAX_PATH is not defined in standard c library...

FILENAME_MAX is defined in bits/stdiolim.h in case of GNU c library

#define FILENAME_MAX 4096

instead you can define MAX_PATH macro for yourself.

 

[Martin Ambuhl]

I was just wondering whether there is any MAX_PATH macro in C\C++? If not
what is a safe value to assume for maximum path length?

FILENAME_MAX is a macro defined in <stdio.h> 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.

 

[Jack Klein]

comp.lang.c:

Top posting is considered rude in this group.

MAX_PATH is not defined in standard c library...

FILENAME_MAX is defined in bits/stdiolim.h in case of GNU c library

The GNU C library is off-topic here. In any case, FILENAME_MAX is
defined in <stdio.h> on every conforming C implementation for hosted
environments.

 

[Keith Thompson]

FILENAME_MAX is a macro defined in <stdio.h> 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.

Which doesn't guarantee that there aren't valid file names longer than
FILENAME_MAX.

 

[Dan Pop]

MAX_PATH is not defined in standard c library...

FILENAME_MAX is defined in bits/stdiolim.h in case of GNU c library

#define FILENAME_MAX 4096

instead you can define MAX_PATH macro for yourself.

If one could define MAX_PATH in a portable manner, there would be no need
for FILENAME_MAX in <stdio.h>.

Dan

 

[Dan Pop]

Which doesn't guarantee that there aren't valid file names longer than
FILENAME_MAX.

OTOH, a decent implementation should provide a definition of FILENAME_MAX
that is adequate for most purposes.

Note that FILENAME_MAX is not relevant to any file name generated by
the implementation, so there are no buffer overrun issues involved.
tmpnam() generates file names that are guaranteed not to exceed
L_tmpnam - 1 bytes.

Dan

 

[Keith Thompson]

OTOH, a decent implementation should provide a definition of FILENAME_MAX
that is adequate for most purposes.

Agreed, but it's important to keep in mind that it may not be adequate
for *all* purposes. A program that gets a file name from an external
source (command-line argument, user input, etc.) cannot safely assume
that the name will fit in FILENAME_MAX bytes, though it wouldn't be
entirely unreasonable to reject the name if it doesn't. (On the other
hand, it's not that hard to accept file names of any arbitrary
length.)

Note that FILENAME_MAX is not relevant to any file name generated by
the implementation, so there are no buffer overrun issues involved.
tmpnam() generates file names that are guaranteed not to exceed
L_tmpnam - 1 bytes.

I don't actually see an explicit guarantee that L_tmpnam <= FILENAME_MAX,
but having L_tmpname > FILENAME_MAX would be perverse.

 

[Dan Pop]

Agreed, but it's important to keep in mind that it may not be adequate
for *all* purposes. A program that gets a file name from an external
source (command-line argument, user input, etc.) cannot safely assume
that the name will fit in FILENAME_MAX bytes, though it wouldn't be
entirely unreasonable to reject the name if it doesn't. (On the other
hand, it's not that hard to accept file names of any arbitrary
length.)

If the thing already exists as a string (e.g. obtained from argv) there is
little point in bothering with checking its length. FILENAME_MAX is
supposed to help the programmer when allocationg memory for storing a
file name coming from a stream. In such contexts, there is little point
in trying to accomodate arbitrarily long strings: allocate FILENAME_MAX
characters and complain if the name doesn't fit (terminating null
character included).

Note that HPUX is (in)famous for misinterpreting the definition of
FILENAME_MAX and providing a next to useless value for it.

I don't actually see an explicit guarantee that L_tmpnam <= FILENAME_MAX,
but having L_tmpname > FILENAME_MAX would be perverse.

Who was talking about any guarantees here? The point was that, when the
file name comes from tmpnam(), FILENAME_MAX is entirely irrelevant.

Dan

 

[Keith Thompson]

(e-mail address removed) (Dan Pop) writes: [...]

OTOH, a decent implementation should provide a definition of FILENAME_MAX
that is adequate for most purposes.

Agreed, but it's important to keep in mind that it may not be adequate
for *all* purposes. A program that gets a file name from an external
source (command-line argument, user input, etc.) cannot safely assume
that the name will fit in FILENAME_MAX bytes, though it wouldn't be
entirely unreasonable to reject the name if it doesn't. (On the other
hand, it's not that hard to accept file names of any arbitrary
length.)

If the thing already exists as a string (e.g. obtained from argv) there is
little point in bothering with checking its length. FILENAME_MAX is
supposed to help the programmer when allocationg memory for storing a
file name coming from a stream. In such contexts, there is little point
in trying to accomodate arbitrarily long strings: allocate FILENAME_MAX
characters and complain if the name doesn't fit (terminating null
character included).

That's a quality of implementation issue -- quality of the program,
not of the C implementation. Personally, I'd prefer a program that
accepts file names from an external source to be able to handle
arbitrarily long names rather than limiting them to FILENAME_MAX, but
as long as FILENAME_MAX is defined fairly reasonably, rejecting very
long names isn't too horrendously unfriendly.

Note that HPUX is (in)famous for misinterpreting the definition of
FILENAME_MAX and providing a next to useless value for it.

Which could be an argument against using FILENAME_MAX as an upper
bound on accepted file names.

Who was talking about any guarantees here? The point was that, when the
file name comes from tmpnam(), FILENAME_MAX is entirely irrelevant.

You're right, I misunderstood.

 

[Dan Pop]

Which could be an argument against using FILENAME_MAX as an upper
bound on accepted file names.

On the contrary, this is the only way to convince HP to fix their
user unfriendly implementation: make as many users as possible complain.

Dan

 

[Keith Thompson]

On the contrary, this is the only way to convince HP to fix their
user unfriendly implementation: make as many users as possible complain.

Complain away. In the meantime, I'm not going to write software that
doesn't work on HP-UX. Users aren't going to care whether it's the
fault of the OS or of the application programmer.

 

[Dan Pop]

Complain away. In the meantime, I'm not going to write software that
doesn't work on HP-UX.

Who says it doesn't work? It only suffers from a limitation imposed by
the vendor.

Users aren't going to care whether it's the
fault of the OS or of the application programmer.

They will complain to the application programmer, and the application
programmer will explain them that the limitation is imposed by the vendor.

If you try accomodating every piece of brain damage in every real
implementation, you will soon discover that you can forget about most
of the C standard library features. If you don't care about trying to
convince the vendors to improve their implementations, you have two
choices: either use the standard features and conditionally bypass
them on implementations known to get them wrong, e.g.

#include <stdio.h>
#ifdef __hpux
#undef FILENAME_MAX
#define FILENAME_MAX 1024
#endif

or simply ignore the C standard and use whatever you know it works on the
implementations you intend to support.

I'd rather test the length of a user supplied file name against
FILENAME_MAX and reject file names exceeding it than silently accepting
*anything* provided as a file name and run the risk that the OS truncates
it behind my back. I prefer to deal with the complaint "your program
is rejecting this file name because it is too long" than with "your
program is silently truncating my file name".

Dan

 

[Keith Thompson]

Who says it doesn't work? It only suffers from a limitation imposed by
the vendor.

A Google search indicates that HP-UX defines FILENAME_MAX as 14, which
is absurd.

Only if I choose to use FILENAME_MAX. If the implementation sets
FILENAME_MAX to 14, that just means that the implementation doesn't
guarantee that a filename longer than that can be opened successfully.
There's no implication that an attempt to open a longer file name will
fail. If I get a file name from an external source, I don't much care
whether the implementation *guarantees* that an attempt to open it
won't fail because it's too long; I'd rather try to open it and handle
the error if fopen() tells me it failed.

Given the existence of systems on which file names can be arbitrarily
long, I don't see that FILENAME_MAX is particularly useful.

They will complain to the application programmer, and the application
programmer will explain them that the limitation is imposed by the vendor.

But it isn't imposed by the vendor. An application programmer is not
required to reject file names longer than FILENAME_MAX.

I've used HP-UX systems, and I've used (and written) application
programs that open files with names much longer than 14 characters.
If one program fails, I'll ask the programmer to fix it; if he tells
me that he has no choice because of the value of FILENAME_MAX, I'll
point him to the plethora of other programs that quite properly ignore
HP-UX's braindead FILENAME_MAX definition.

[...]

I'd rather test the length of a user supplied file name against
FILENAME_MAX and reject file names exceeding it than silently accepting
*anything* provided as a file name and run the risk that the OS truncates
it behind my back. I prefer to deal with the complaint "your program
is rejecting this file name because it is too long" than with "your
program is silently truncating my file name".

I've been assuming that fopen(), given a string longer than
FILENAME_MAX, will either open the named file or fail to do so. It
didn't occur to me that it would silently truncate the name. I
suppose that's possible, but I don't know of any system that actually
does so. Do you?

In my (admittedly limited) experience, it's safer to assume that
fopen() will fail sensibly given an overly long filename that to
assume that FILENAME_MAX is defined sensibly.

 

[Dag Viken]

I was just wondering whether there is any MAX_PATH macro in C\C++? If not
what is a safe value to assume for maximum path length?

Max filename size is system dependent. In VC _MAX_PATH (=260) is defined in
stdlib.h. If you need to support multiple OS's you will some #ifdef
construct to differentiate them
..

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:
[...]

Who says it doesn't work? It only suffers from a limitation imposed by
the vendor.

A Google search indicates that HP-UX defines FILENAME_MAX as 14, which
is absurd.

It is not entirely absurd. One of the filesystems still supported by
HP-UX has the historical Unix limitation of 14 characters per filename.
And if the user types a filename with no path components, 14 is the
effective limit. The problem is that the standard C library completely
ignores the structure of a file name and only one limit is not enough,
as demonstrated by the above example.

Given the existence of systems on which file names can be arbitrarily
long, I don't see that FILENAME_MAX is particularly useful.

As long as there are systems which limit the size of a file name,
FILENAME_MAX is *extremely* useful in a portable programming context:
you have no control over what happens if you pass a library function a
name longer than FILENAME_MAX characters.

But it isn't imposed by the vendor. An application programmer is not
required to reject file names longer than FILENAME_MAX.

An application programmer trying to use such file names *in a portable
context* is an irresponsible fool. You can do that *only* if you know
how the system reacts when presented with such file names. But then,
you're out of c.l.c standards of topicality.

I've been assuming that fopen(), given a string longer than
FILENAME_MAX, will either open the named file or fail to do so. It
didn't occur to me that it would silently truncate the name. I
suppose that's possible, but I don't know of any system that actually
does so. Do you?

In my (admittedly limited) experience, it's safer to assume that
fopen() will fail sensibly given an overly long filename that to
assume that FILENAME_MAX is defined sensibly.

When we're talking about *portable* programming, we cannot rely on our
personal experiences or intuitions: we have no clue about how systems
unknown to us respond when abused with file names longer than
FILENAME_MAX characters. And, although FILENAME_MAX is defined in the
context of fopen(), there are other standard functions that take file
names as arguments (rename, remove) and whose behaviour need not be
as sensible as we wish when abused.

Dan

 

[Keith Thompson]

When we're talking about *portable* programming, we cannot rely on our
personal experiences or intuitions: we have no clue about how systems
unknown to us respond when abused with file names longer than
FILENAME_MAX characters. And, although FILENAME_MAX is defined in the
context of fopen(), there are other standard functions that take file
names as arguments (rename, remove) and whose behaviour need not be
as sensible as we wish when abused.

"The fopen function opens the file whose name is the string pointed to
by filename, and associates a stream with it." (C99 7.19.5.3p2)

"The fopen function returns a pointer to the object controlling the
stream. If the open operation fails, fopen returns a null pointer."
(C99 7.19.5.3p8)

If I call fopen() with a file name "this_is_a_very_long_file_name.txt",
and it opens a file named "this_is_a_very", it's not opening the file
whose name is the string pointed to by filename.

As for HP-UX defining FILENAME_MAX as 14, I think HP has at least
committed an off-by-one error. I recall that early Unix systems
limited file names to 14 characters. FILENAME_MAX "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". An array holding a string
of length 14 has to be at least 15 characters long. (That doesn't
make HP-UX's C implementation non-conforming, it just means that they
(absurdly) choose guarantee that files with 13-character names, but
not with 14-character names, can be opened.)

 

[Dag Viken]

Max filename size is system dependent. In VC _MAX_PATH (=260) is defined in
stdlib.h. If you need to support multiple OS's you will need some #ifdef
construct to differentiate them.

Sorry, missing word ("need") - makes sense now!

 

[Dan Pop]

"The fopen function opens the file whose name is the string pointed to
by filename, and associates a stream with it." (C99 7.19.5.3p2)

"The fopen function returns a pointer to the object controlling the
stream. If the open operation fails, fopen returns a null pointer."
(C99 7.19.5.3p8)

If I call fopen() with a file name "this_is_a_very_long_file_name.txt",
and it opens a file named "this_is_a_very", it's not opening the file
whose name is the string pointed to by filename.

If calling fopen() with "this_is_a_very_long_file_name.txt" invokes
undefined behaviour, all the bets are off.

As for HP-UX defining FILENAME_MAX as 14, I think HP has at least
committed an off-by-one error.

Yes, but it's on the safe side: any file name of 13 characters or less is
OK for the file system under question. Since this is a QoI issue, the
conformance of the HP-UX implementation is not affected.

Dan