Does ANSI C have something like PATHMAX or MAX_PATH?

S

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
 
M

Martin Ambuhl

Sunner said:
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.
 
P

pete

Sunner said:
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.
 
M

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
 
R

Ravi Uday

Sunner Sun said:
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
 
B

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.
 
M

Martin Ambuhl

Ravi said:
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.
 
R

Ravi Uday

Path Field Limits
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
 
C

CBFalconer

Ravi said:
<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).
 
R

Richard Bos

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
 
B

Barry Schwarz

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>>
 
V

Villy Kruse

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
 
R

Richard Bos

Barry Schwarz said:
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
 
D

Dan Pop

In said:
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
 
C

CBFalconer

Villy said:
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

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.
 
I

Ike Naar

: 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
 
D

Dan Pop

In said:
: 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top