Menu ▾ ▴

#1527 PATH_MAX is unconditionally set, incorrectly

closed-fixed
Earnie Boyd
MinGW (57)
2012-08-03
2011-03-21
Chris Spiegel
No

In mingw/include/limits.h, PATH_MAX is unconditionally set. However, PATH_MAX is not part of standard C, so if -std=c99 or -std=c89 is passed to gcc, PATH_MAX should not exist, as it is not in the implementation's namespace.

The obvious fix would be to wrap the definition in #ifndef __STRICT_ANSI__, but sys/param.h defines MAXPATHLEN in terms of PATH_MAX, so an actual fix would need to be slightly smarter (since sys/param.h, not being a standard C header, is not bound to follow C's namespace rules).

Discussion

  • Earnie Boyd

    Earnie Boyd - 2011-03-21
    • assigned_to: nobody --> chicares
     

  • Earnie Boyd

    Earnie Boyd - 2011-03-21

    PATH_MAX is a POSIX definition and not a C definition. MAX_PATH is what Windows uses to define the limit and the limit exists regardless of the C definition. So, since PATH_MAX is POSIX I agree that a __STRICT_ANSI__ guard should be applied but it should not be applied to MAX_PATH.

    My searching for MAXPATHLEN leads me to conclude that MAXPATHLEN is a leftover from original UNIX that shouldn't be used any longer and the __STRICT_ANSI__ guard should also be applied to it or we could remove it completely. The danger of removing it becomes someone still using it, especially Cygwin. Microsoft doesn't define it from what I can tell.

     

  • Earnie Boyd

    Earnie Boyd - 2011-03-27
    • assigned_to: chicares --> ir0nh34d
     

  • Earnie Boyd

    Earnie Boyd - 2012-08-03
    • assigned_to: ir0nh34d --> earnie
    • status: open --> closed-fixed
     

  • Earnie Boyd

    Earnie Boyd - 2012-08-03

    The problem you report has caused modification in some fashion in
    the official CVS for the given package. The w32api and
    mingw-runtime official CVS reside in the winsup CVS directory tree for Cygwin. If you still find problems then please open a
    new report.