Does ANSI C have something like PATHMAX or MAX_PATH?

[Sunner Sun]

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

Thank you.
Sunner Sun

[Martin Ambuhl]

Sunner Sun wrote:

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

The standard macro FILENAME_MAX should be large enough to specify a
string which will hold the longest name which can be used to open a
file. The macro is standard, it's _value_ will change according to
platform, just as UINT_MAX or DBL_EPSILON will. That's why they are
macros instead of specified literal values.

[pete]

Sunner Sun wrote:

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

All standard library macro definitions are platform dependant.

--
pete

[Michael B Allen]

On Thu, 01 Apr 2004 20:40:13 -0500, Sunner Sun wrote:

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

PATH_MAX is probably what you're thinking of. I don't recall which
standard defines it but it isn't ANSI C. It's also not going to be a
specific value across platforms if that's what you mean by "platform
dependant".

Mike

[Alan Balmer]

On Fri, 02 Apr 2004 05:11:35 -0500, Michael B Allen
<mb*****@ioplex.com> wrote:

On Thu, 01 Apr 2004 20:40:13 -0500, Sunner Sun wrote:

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?
PATH_MAX is probably what you're thinking of. I don't recall which
standard defines it but it isn't ANSI C.

POSIX defines it.
It's also not going to be a
specific value across platforms if that's what you mean by "platform
dependant".

Mike

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <7f********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On Fri, 02 Apr 2004 05:11:35 -0500, Michael B Allen
<mb*****@ioplex.com> wrote:

On Thu, 01 Apr 2004 20:40:13 -0500, Sunner Sun wrote:

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

PATH_MAX is probably what you're thinking of. I don't recall which
standard defines it but it isn't ANSI C.

POSIX defines it.

C defines the somewhat equivalent FILENAME_MAX.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <uo********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 8 Apr 2004 17:52:57 GMT, Da*****@cern.ch (Dan Pop) wrote:

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.

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

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.

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.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ravi Uday]

"Sunner Sun" <su********@163.com> wrote in message news:<c4**********@news.yaako.com>...

Hi!

I have looked through the FAQ but found nothing about it. :-)

It seems that this kind of macro is platform dependent, doesn't it?

Thank you.
Sunner Sun

Path Field Limits
#include <stdlib.h>
These constants define the maximum length for the path and for the
individual fields within the path.

Constant Meaning
_MAX_DIR Maximum length of directory component
_MAX_DRIVE Maximum length of drive component
_MAX_EXT Maximum length of extension component
_MAX_FNAME Maximum length of filename component
_MAX_PATH Maximum length of full path
The sum of the fields should not exceed _MAX_PATH.

FILENAME_MAX - Maximum permissible length for filename

- Ravi

[Ben Pfaff]

ra*****@yahoo.com (Ravi Uday) writes:

Path Field Limits
#include <stdlib.h>
These constants define the maximum length for the path and for the
individual fields within the path.

Constant Meaning
_MAX_DIR Maximum length of directory component
_MAX_DRIVE Maximum length of drive component
_MAX_EXT Maximum length of extension component
_MAX_FNAME Maximum length of filename component
_MAX_PATH Maximum length of full path
These are all non-standard.
The sum of the fields should not exceed _MAX_PATH.
This is also non-standard.
FILENAME_MAX - Maximum permissible length for filename

This is standard.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Martin Ambuhl]

Ravi Uday wrote:

Path Field Limits
#include <stdlib.h>
These constants define the maximum length for the path and for the
individual fields within the path.

Constant Meaning
_MAX_DIR Maximum length of directory component
_MAX_DRIVE Maximum length of drive component
_MAX_EXT Maximum length of extension component
_MAX_FNAME Maximum length of filename component
_MAX_PATH Maximum length of full path
The sum of the fields should not exceed _MAX_PATH.

None of these _MAX_* macros are standard C. Almost no macros* in
standard C begin with an underscore, and you would usually be right in
assuming any such macro to be implementation-specific.
Implementation-specific questions are off-topic here;
implementation-specific answers are much worse. Don't do this; you have
done a very bad thing.

* Standard keywords and identifiers beginning with an underscore include
__LINE__, __FILE__, __DATE__, __TIME__, __STDC__, __STDC_VERSION__,
__STDC_ISO_10646__, __func__, __STDC_IEC_559__,
__STDC_IEC_559_COMPLEX__, Complex, _Complex_I, _Imaginary, _Imaginary_I,
_Bool, __bool_true_and_false_are_defined, _Pragma, __STDC_LIMIT_MACROS,
__STDC_CONSTANT_MACROS, _IOFBF, _IOLBF, _IONBF. Very few of these are
relevant to people without compilers aspiring to C99 conformance.

[Ravi Uday]

> > Path Field Limits

#include <stdlib.h>
<snip>
Constant Meaning
_MAX_DIR Maximum length of directory component
_MAX_DRIVE Maximum length of drive component
_MAX_EXT Maximum length of extension component
_MAX_FNAME Maximum length of filename component
_MAX_PATH Maximum length of full path
The sum of the fields should not exceed _MAX_PATH.

None of these _MAX_* macros are standard C. Almost no macros* in
standard C begin with an underscore, and you would usually be right in
assuming any such macro to be implementation-specific.
Implementation-specific questions are off-topic here;
implementation-specific answers are much worse. Don't do this; you have
done a very bad thing.

<SNIP>

Upon searching in the MSDN, i came across these _MAX_'s
Since the help file said you need to include <stdlib.h> for these
i presumed that these would be a part of C standard. Sorry I was ignorant.

- Ravi

[CBFalconer]

Ravi Uday wrote:

<SNIP>

Upon searching in the MSDN, i came across these _MAX_'s Since the
help file said you need to include <stdlib.h> for these i presumed
that these would be a part of C standard. Sorry I was ignorant.

Get yourself a copy of N869.txt and search it for such items. If
they aren't there they are not standard (with one exception that I
can't remember just now).

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Bos]

ra*****@yahoo.com (Ravi Uday) wrote:

_MAX_DIR Maximum length of directory component

None of these _MAX_* macros are standard C. Almost no macros* in
standard C begin with an underscore, and you would usually be right in
assuming any such macro to be implementation-specific.

Upon searching in the MSDN, i came across these _MAX_'s

Well, there's your mistake, then. _Never_ expect Microsoft to be
correct, or, for that matter, honest, when it comes to what is Standard
and what is their own embrace-and-extend stuff.

Richard

[Barry Schwarz]

On Tue, 06 Apr 2004 12:25:11 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

ra*****@yahoo.com (Ravi Uday) wrote:

> > _MAX_DIR Maximum length of directory component > None of these _MAX_* macros are standard C. Almost no macros* in
> standard C begin with an underscore, and you would usually be right in
> assuming any such macro to be implementation-specific.

Upon searching in the MSDN, i came across these _MAX_'s

Well, there's your mistake, then. _Never_ expect Microsoft to be
correct, or, for that matter, honest, when it comes to what is Standard
and what is their own embrace-and-extend stuff.

I really doubt if that criticism can be directed to only one company.
<<Remove the del for email>>

[Villy Kruse]

On 7 Apr 2004 04:45:13 GMT,
Barry Schwarz <sc******@deloz.net> wrote:

On Tue, 06 Apr 2004 12:25:11 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

Well, there's your mistake, then. _Never_ expect Microsoft to be
correct, or, for that matter, honest, when it comes to what is Standard
and what is their own embrace-and-extend stuff.

I really doubt if that criticism can be directed to only one company.

ANSI C header files on unix system often have definitions unrelated to
ANSI C. For example the popen() and pclose() function in stdio.h can
hardly be called a ANSI C function. In that case the blame goes to POSIX.
Villy

[Richard Bos]

Barry Schwarz <sc******@deloz.net> wrote:

On Tue, 06 Apr 2004 12:25:11 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

ra*****@yahoo.com (Ravi Uday) wrote:

Upon searching in the MSDN, i came across these _MAX_'s

Well, there's your mistake, then. _Never_ expect Microsoft to be
correct, or, for that matter, honest, when it comes to what is Standard
and what is their own embrace-and-extend stuff.

I really doubt if that criticism can be directed to only one company.

Certainly not. In fact, next in line, IMO, is not a company but a
non-commercial organisation that shall remain nameless because its
members bloody well know who I mean.

However, M$ _is_ by far the worst perpetrator. I don't think I've ever
seen a single product by them that kept by all useful Standards.

Richard

[Dan Pop]

In <sl****************@station02.ohout.pharmapartners .nl> Villy Kruse <ve*@station02.ohout.pharmapartners.nl> writes:

On 7 Apr 2004 04:45:13 GMT,
Barry Schwarz <sc******@deloz.net> wrote:

On Tue, 06 Apr 2004 12:25:11 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

Well, there's your mistake, then. _Never_ expect Microsoft to be
correct, or, for that matter, honest, when it comes to what is Standard
and what is their own embrace-and-extend stuff.

I really doubt if that criticism can be directed to only one company.

ANSI C header files on unix system often have definitions unrelated to
ANSI C. For example the popen() and pclose() function in stdio.h can
hardly be called a ANSI C function. In that case the blame goes to POSIX.

Read those Unix headers carefully. On any conforming POSIX system, the
declarations of popen and pclose in <stdio.h> are guarded by some
POSIX-specific macros:

fangorn:~/tmp 283> cat test.c
#include <stdio.h>

int main(void)
{
popen();
pclose();
return 0;
}
fangorn:~/tmp 284> gcc -ansi -Wall test.c
test.c: In function `main':
test.c:5: warning: implicit declaration of function `popen'
test.c:6: warning: implicit declaration of function `pclose'
fangorn:~/tmp 285> gcc test.c
test.c: In function `main':
test.c:5: error: too few arguments to function `popen'
test.c:6: error: too few arguments to function `pclose'

As you can see, there is no definition of popen or pclose in <stdio.h>
if the compiler is invoked in conforming mode.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <c5**********@sunnews.cern.ch> I wrote:

As you can see, there is no definition of popen or pclose in <stdio.h> ^^^^^^^^^^if the compiler is invoked in conforming mode.

s/definition/declaration

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Villy Kruse wrote:

Barry Schwarz <sc******@deloz.net> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Well, there's your mistake, then. _Never_ expect Microsoft to
be correct, or, for that matter, honest, when it comes to what
is Standardand what is their own embrace-and-extend stuff.

I really doubt if that criticism can be directed to only one
company.

ANSI C header files on unix system often have definitions
unrelated to ANSI C. For example the popen() and pclose()
function in stdio.h can hardly be called a ANSI C function. In
that case the blame goes to POSIX.

The better systems document portability, such as:
Portability
-----------

not ANSI, POSIX

and will not pick up a non-ansi prototype from stdio.h when the
compiler is used in a conforming mode. For gcc this means -ansi
-pedantic.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Ike Naar]

Martin Ambuhl <ma*****@earthlink.net> wrote:
: Sunner Sun wrote:
:> I have looked through the FAQ but found nothing about it. :-)
:> It seems that this kind of macro is platform dependent, doesn't it?

: The standard macro FILENAME_MAX should be large enough to specify a
: string which will hold the longest name which can be used to open a
: file. The macro is standard, it's _value_ will change according to
: platform, just as UINT_MAX or DBL_EPSILON will. That's why they are
: macros instead of specified literal values.

But be careful, FILENAME_MAX might be not as large as you might expect,
e.g. on my system (HP-UX B.11.00 A 9000/712) FILENAME_MAX (from <stdio.h>)
equals 14 (that's fourteen).

Kind regards,
Ike

--
mail to ike at iae dot nl

[Dan Pop]

In <m%****************@typhoon.bart.nl> Ike Naar <no****@nospam.invalid> writes:

Martin Ambuhl <ma*****@earthlink.net> wrote:
: Sunner Sun wrote:
:> I have looked through the FAQ but found nothing about it. :-)
:> It seems that this kind of macro is platform dependent, doesn't it?

: The standard macro FILENAME_MAX should be large enough to specify a
: string which will hold the longest name which can be used to open a
: file. The macro is standard, it's _value_ will change according to
: platform, just as UINT_MAX or DBL_EPSILON will. That's why they are
: macros instead of specified literal values.

But be careful, FILENAME_MAX might be not as large as you might expect,
e.g. on my system (HP-UX B.11.00 A 9000/712) FILENAME_MAX (from <stdio.h>)
equals 14 (that's fourteen).

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.

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On 8 Apr 2004 12:37:37 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <m%****************@typhoon.bart.nl> Ike Naar <no****@nospam.invalid> writes:

Martin Ambuhl <ma*****@earthlink.net> wrote:
: Sunner Sun wrote:
:> I have looked through the FAQ but found nothing about it. :-)
:> It seems that this kind of macro is platform dependent, doesn't it?

: The standard macro FILENAME_MAX should be large enough to specify a
: string which will hold the longest name which can be used to open a
: file. The macro is standard, it's _value_ will change according to
: platform, just as UINT_MAX or DBL_EPSILON will. That's why they are
: macros instead of specified literal values.

But be careful, FILENAME_MAX might be not as large as you might expect,
e.g. on my system (HP-UX B.11.00 A 9000/712) FILENAME_MAX (from <stdio.h>)
equals 14 (that's fourteen).
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.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <ge********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 8 Apr 2004 12:37:37 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <m%****************@typhoon.bart.nl> Ike Naar <no****@nospam.invalid> writes:

Martin Ambuhl <ma*****@earthlink.net> wrote:
: Sunner Sun wrote:
:> I have looked through the FAQ but found nothing about it. :-)
:> It seems that this kind of macro is platform dependent, doesn't it?

: The standard macro FILENAME_MAX should be large enough to specify a
: string which will hold the longest name which can be used to open a
: file. The macro is standard, it's _value_ will change according to
: platform, just as UINT_MAX or DBL_EPSILON will. That's why they are
: macros instead of specified literal values.

But be careful, FILENAME_MAX might be not as large as you might expect,
e.g. on my system (HP-UX B.11.00 A 9000/712) FILENAME_MAX (from <stdio.h>)
equals 14 (that's fourteen).

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.

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.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On 8 Apr 2004 17:52:57 GMT, Da*****@cern.ch (Dan Pop) wrote:

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.

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.

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."
--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <uo********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 8 Apr 2004 17:52:57 GMT, Da*****@cern.ch (Dan Pop) wrote:

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.

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

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.

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.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de