Does ANSI C have something like PATHMAX or MAX_PATH?

Discussion in 'C Programming' started by Sunner Sun, Apr 2, 2004.

  1. Sunner Sun

    Sunner Sun Guest

    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
    Sunner Sun, Apr 2, 2004
    #1
    1. Advertising

  2. 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.
    Martin Ambuhl, Apr 2, 2004
    #2
    1. Advertising

  3. Sunner Sun

    pete Guest

    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
    pete, Apr 2, 2004
    #3
  4. 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
    Michael B Allen, Apr 2, 2004
    #4
  5. Sunner Sun

    Alan Balmer Guest

    On Fri, 02 Apr 2004 05:11:35 -0500, Michael B Allen
    <> 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
    Alan Balmer, Apr 2, 2004
    #5
  6. Sunner Sun

    Dan Pop Guest

    In <> Alan Balmer <> writes:

    >On Fri, 02 Apr 2004 05:11:35 -0500, Michael B Allen
    ><> 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 Pop, Apr 2, 2004
    #6
  7. Sunner Sun

    Ravi Uday Guest

    "Sunner Sun" <> wrote in message news:<c4ig9u$2h7$>...
    > 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
    Ravi Uday, Apr 5, 2004
    #7
  8. Sunner Sun

    Ben Pfaff Guest

    (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[]="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\
    );}return 0;}
    Ben Pfaff, Apr 5, 2004
    #8
  9. 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.
    Martin Ambuhl, Apr 5, 2004
    #9
  10. Sunner Sun

    Ravi Uday Guest

    > > 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
    Ravi Uday, Apr 6, 2004
    #10
  11. Sunner Sun

    CBFalconer Guest

    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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Apr 6, 2004
    #11
  12. Sunner Sun

    Richard Bos Guest

    (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
    Richard Bos, Apr 6, 2004
    #12
  13. On Tue, 06 Apr 2004 12:25:11 GMT, (Richard
    Bos) wrote:

    > (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>>
    Barry Schwarz, Apr 7, 2004
    #13
  14. Sunner Sun

    Villy Kruse Guest

    On 7 Apr 2004 04:45:13 GMT,
    Barry Schwarz <> wrote:


    > On Tue, 06 Apr 2004 12:25:11 GMT, (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
    Villy Kruse, Apr 7, 2004
    #14
  15. Sunner Sun

    Richard Bos Guest

    Barry Schwarz <> wrote:

    > On Tue, 06 Apr 2004 12:25:11 GMT, (Richard
    > Bos) wrote:
    >
    > > (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
    Richard Bos, Apr 7, 2004
    #15
  16. Sunner Sun

    Dan Pop Guest

    In <> Villy Kruse <> writes:

    >On 7 Apr 2004 04:45:13 GMT,
    > Barry Schwarz <> wrote:
    >
    >
    >> On Tue, 06 Apr 2004 12:25:11 GMT, (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:
    Dan Pop, Apr 7, 2004
    #16
  17. Sunner Sun

    Dan Pop Guest

    In <c510ob$41f$> 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:
    Dan Pop, Apr 7, 2004
    #17
  18. Sunner Sun

    CBFalconer Guest

    Villy Kruse wrote:
    > Barry Schwarz <> wrote:
    >> (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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Apr 7, 2004
    #18
  19. Sunner Sun

    Ike Naar Guest

    Martin Ambuhl <> 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
    Ike Naar, Apr 8, 2004
    #19
  20. Sunner Sun

    Dan Pop Guest

    In <m%8dc.902$%> Ike Naar <> writes:

    >Martin Ambuhl <> 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:
    Dan Pop, Apr 8, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sergey
    Replies:
    4
    Views:
    4,142
    Sergey
    Feb 14, 2006
  2. Tim Golden
    Replies:
    2
    Views:
    311
    Sergey
    Feb 14, 2006
  3. Tim Golden
    Replies:
    3
    Views:
    985
    Sergey
    Feb 15, 2006
  4. Tim Golden
    Replies:
    2
    Views:
    334
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Feb 15, 2006
  5. sonet

    How to change MAX_PATH value?

    sonet, Nov 28, 2007, in forum: Perl Misc
    Replies:
    2
    Views:
    492
    Ilya Zakharevich
    Dec 4, 2007
Loading...

Share This Page