Does ANSI C have something like PATHMAX or MAX_PATH?
Sunner Sun
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
> 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
>
> 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
> 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
<mba...@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
removebalmerc...@att.net
Dan Pop
>On Fri, 02 Apr 2004 05:11:35 -0500, Michael B Allen
><mba...@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: Dan...@ifh.de
Ravi Uday
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
> 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[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\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
> 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
> > #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
>
> <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 (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Richard Bos
> > > _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
I really doubt if that criticism can be directed to only one company.
<<Remove the del for email>>
Villy Kruse
Barry Schwarz <schw...@deloz.net> wrote:
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
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
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 Pop
>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
CBFalconer
> Barry Schwarz <schw...@deloz.net> wrote:
>> r...@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
> >
> > 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.
Ike Naar
: Sunner Sun wrote:
:> I have looked through the FAQ but found nothing about it. :-)
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
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.
Alan Balmer
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
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).
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.
>
>>>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."
Dan Pop
>On 8 Apr 2004 17:52:57 GMT, Dan...@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.