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
