[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PATH_MAX with mingw
Re: PATH_MAX with mingw
Sun, 26 Aug 2007 10:58:13 +0200
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 :)