Max Path [Newbie]

[Keith Thompson]

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

Yes, they would be, but I don't see anything in the standard that says
fopen() can invoke undefined behavior, as long as both arguments point
to strings and the second argument has one of the specified values.
As long as those conditions are satisfied, fopen() either succeeds and
returns a pointer to the object controlling the stream, or fails and
returns a null pointer.

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.

Gosh, Dan, I guess you're right. I don't know why I didn't think of
that.

Oh, wait, I did.

Here's what I wrote:

] 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.)

You snipped most of the paragraph, including the part where I
explicitly made the point that HP's off-by-one error doesn't affect
the conformance of their implementation. You then made exactly the
same point yourself. Why?

If defining FILENAME_MAX as 14 is conforming, so is defining it as 2,
or even 1 (the latter would imply that the implementation doesn't
guarantee that any non-empty file name can be fopen()ed). Rejecting
all file names longer than FILENAME_MAX-1 will make a program far less
useful on some conforming systems. Allowing arbitrarily long file
names lets the program determine whether a given file name is accepted
by seeing whether fopen() succeeds.

 

[Dan Pop]

Yes, they would be, but I don't see anything in the standard that says
fopen() can invoke undefined behavior, as long as both arguments point
to strings and the second argument has one of the specified values.
As long as those conditions are satisfied, fopen() either succeeds and
returns a pointer to the object controlling the stream, or fails and
returns a null pointer.

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

What if the string in question is not a file name, because it is longer
than FILENAME_MAX?

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.

Gosh, Dan, I guess you're right. I don't know why I didn't think of
that.

Oh, wait, I did.

Here's what I wrote:

] 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.)

You snipped most of the paragraph, including the part where I
explicitly made the point that HP's off-by-one error doesn't affect
the conformance of their implementation. You then made exactly the
same point yourself. Why?

Because I didn't bother reading more than I have quoted. I saw
a pointless remark and I have addressed it. If you knew it was
a pointless remark, why did you feel compelled to make it in the
first place?

If defining FILENAME_MAX as 14 is conforming, so is defining it as 2,
or even 1 (the latter would imply that the implementation doesn't
guarantee that any non-empty file name can be fopen()ed).

An implementation where each and every fopen() call unconditionally
fails is still conforming. We're still on QoI grounds.

Rejecting
all file names longer than FILENAME_MAX-1 will make a program far less
useful on some conforming systems.

QoI counts more than you seem to realise. And I don't make any attempts
to support implementations with an arbitrarily low QoI factor. The C
standard provides FILENAME_MAX with one reason and it is sheer
foolishness to ignore it. YMMV.

Allowing arbitrarily long file
names lets the program determine whether a given file name is accepted
by seeing whether fopen() succeeds.

Unless using them invokes undefined behaviour: why does the standard
specify FILENAME_MAX, if presenting fopen() with an arbitrarily long
string has well defined behaviour?

Dan

 

[Keith Thompson]

Because I didn't bother reading more than I have quoted. I saw
a pointless remark and I have addressed it. If you knew it was
a pointless remark, why did you feel compelled to make it in the
first place?

And you couldn't be bothered to read *the rest of the paragraph*?

Dan, do us all a favor. If you're not willing to take the time to
read an entire article, don't bother posting a followup. It wastes
your time and everyone else's, and it doesn't reflect well on your
reading comprehension skills. I honestly expected better of you.

In any case, the remark was not pointless. I was discussing the basis
for one implementation's definition of FILENAME_MAX in relation to the
standard's requirements.

 

[Dan Pop]

In any case, the remark was not pointless. I was discussing the basis
for one implementation's definition of FILENAME_MAX in relation to the
standard's requirements.

The standard doesn't really require anything about FILENAME_MAX, except
that it must be defined as a positive integer constant expression. The
rest is a QoI issue and one implementation provide a very low quality
definition of it. That's all. Nothing worth writing home about.

Dan