bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATH_MAX with mingw


From: Sylvain Beucler
Subject: Re: PATH_MAX with mingw
Date: Sun, 26 Aug 2007 10:58:13 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Bruno Haible wrote:
> Hello Sylvain,
> 
> Sylvain Beucler wrote:
> > I see that under Woe, MAX_PATH is the equivalent for PATH_MAX, and is
> > set to 260 in MinGW's headers (windef.h).
> 
> An old copy of mingw defines PATH_MAX already in <limits.h>:
> 
>   /*
>    * 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)
> 
> So, it may be that MAX_PATH is not the same (semantically) as PATH_MAX.
> 
> > Would it be interesting to check for MAX_PATH in pathmax.h, instead of
> > defaulting to 256?
> 
> The default of 256 is not used, since <limits.h> already defines PATH_MAX.
> This looks like the right thing to me: why should gnulib override the
> definition from <limits.h> without a good reason?

Hmm, sorry I confused myself.

(Btw, I'm working, as part of the GNU FreeDink project, on porting an
application that was written in visual c++ 5, converting it to
GNU/Linux, autoconfiscating, etc.)

With more tests PATH_MAX is indeed defined in mingw (newer versions
did not change your excerpt).

PATH_MAX is however not defined under the visual c++ 6 / free version
that I'm using for the port. Its documentation mentions that _MAX_PATH
(the Woe-specific) is the "maximm length of full path". It also
defines aother elements such as _MAX_DRIVE or _MAX_EXT and says that
"The sum of the fields should not exceed _MAX_PATH". In its headers,
the MAX_PATH constant itself is used several times to dimention char*
arrays, and is set to 260.

So supporting MAX_PATH is essentially supporting visual c++ more
precisely (I'm not sure that's what I want). It depends on whether
gnulib's portability goal extends to supporting unmodified W32API. Is
that the case?


Jim Meyering wrote:
> Hi Sylvain,
> 
> Thanks for letting us know.
> 
> For starters, in code intended to be portable, it's best not
> to rely on PATH_MAX, if at all possible.  At a bare minimum,
> don't use it as an array size, and don't try to allocate
> PATH_MAX bytes from the heap.  On some systems, PATH_MAX
> can be very large.  On the Hurd, it's not defined at all.

Hmmm, I inherited such practices from the code I'm porting, that
looked pretty convenient :/ Would you recommend *alloc'ing as needed
and checking for ENAMETOOLONG instead?

> As for adjusting the code to let mingw applications use
> four more bytes, it sounds like it wouldn't hurt, but isn't
> there a definition of PATH_MAX in <limits.h>?
> It looks like there used to be, at least.

Sorry about that. I hit this issue last week, before seeing yesterday
that it was handled by gnulib, and apparently I assumed PATH_MAX
wouldn't work with mingw without testing - but it does :)

-- 
Sylvain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]