Re: [MinGW-dvlpr] MinGW headers: conflicting definitions: PATH_MAX vs. MAX_PATH

[Earnie B. <ea...@us...>]

Quoting Keith Marshall <kei...@us...>:

> Hello All,
>
> In /mingw/include/stdlib, I see the following definition for MAX_PATH, and
> its Microsoft alias, _MAX_PATH
>
>  /*
>   * Definitions for path name functions.
>   * NOTE: All of these values have simply been chosen to be conservatively
> high.
>   *       Remember that with long file names we can no longer depend on
>   *       extensions being short.
>   */
>  #ifndef __STRICT_ANSI__
>
>  #ifndef MAX_PATH
>  #define MAX_PATH        (260)
>  #endif
>
>  #define _MAX_PATH       MAX_PATH
>
> whereas, in /mingw/include/limits.h, I see
>
>  /*
>   * File system limits
>   *
>   * TODO: NAME_MAX and OPEN_MAX are file system limits or not? Are they the
>   *       same as FILENAME_MAX and FOPEN_MAX from stdio.h?
>   * NOTE: Apparently the actual size of PATH_MAX is 260, but a space is
>   *       required for the NUL. TODO: Test?
>   */
>  #define PATH_MAX        (259)
>
--8<--
>
> So, even though POSIX compliance isn't necessarily a major concern, we would
> appear to be ok on the minimum value constraint, but why is PATH_MAX defined
> to be less than MAX_PATH?  Surely, both should be defined as 260?
>
> Curiously, the SUSv3 specification for the realpath() function says that it
> returns a canonically resolved absolute path, up to a maximum of PATH_MAX
> bytes, and then goes on to give an example showing a user allocated return
> buffer of PATH_MAX+1 bytes;  is this the source of the confusion?
>
> Interestingly, Microsoft's closest equivalent for realpath(), _fullpath(),
> will allocate a return buffer, if the user specifies a NULL pointer.
> According to MSDN, the size of this default return buffer is _MAX_PATH bytes.
>
> So, seemingly 260 bytes should be sufficient for a path name;  (is it really
> that small? -- GNU/Linux allows 4096 bytes).  In any event, in case of doubt,
> isn't it better to have the larger definition?
>
> Can anybody shed any light on this apparent anomaly?
>

IIRC, there were issues with MS functions where 260 caused an overrun.  I seem
to recall that this misfeature was OS dependent.  Chris Faylor, do you
remember?

Earnie