[Vm-dev] Failing win64x64 builds - undeclared identifier 'PATH_MAX'

Alistair Grant akgrant0710 at gmail.com
Mon May 15 17:18:12 UTC 2017

On Mon, May 15, 2017 at 07:31:50AM -0700, Eliot Miranda wrote:
> Hi Alistair,
> > On May 15, 2017, at 7:28 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
> > 
> > Hi Ben & Eliot,
> > 
> >> On Sun, May 14, 2017 at 01:30:36AM +0800, Ben Coman wrote:
> >> On Sat, May 13, 2017 at 11:28 AM, Eliot Miranda
> >> <eliot.miranda at gmail.com> wrote:
> >>> 
> >>> Hi Ben,
> >>> 
> >>>    can you tell me what path-related limits limits.h does define on
> >>>    win64?  e.g. there should be something like POSIX_PATH_MAS or
> >>>    XOPEN_PATH_MAX, and if neither of these is available, and
> >>>    nothing else looks relevant we can define a default.  I already
> >>>    put in a default; see
> >>>    platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c
> >> 
> >> I see that here https://git.io/v9QbB and the error disappears in
> >> https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.665
> >> 
> >>> But can we do better on win64/win32?
> >> 
> >> I found  _MAX_PATH in <stdlib.h> at "Path Field Limits" for MSVC
> >> here...  https://msdn.microsoft.com/en-us/library/930f87yf.aspx
> >> 
> >> but I'm not sure how that relates to Cygwin.  I see PATH_MAX defined
> >> in "limits.h" here...
> >> https://cygwin.com/ml/cygwin-patches/2005-q1/msg00084.html
> >> 
> >> cheers -ben
> > 
> > Did you agree on a solution for this?
> > 
> > I'm getting close to finishing the FileAttributes plugin discussed in
> > the "Extending primitiveDirectoryEntry" thread and have also realised
> > that PATH_MAX = 260 on win32.  The plugin also uses the unicode versions
> > of the windows function, so should work with paths up to 32k characters.
> Is there a manifest constant (#define) in Cygwin for the 32k limit?  Which APIs have a 32k limit and which have a 260 limit?
> [why are C APIs such a mess?]

It's a mess seems to be the best summary...

I couldn't find any constant in cygwin for 32k.  Although in some ways
it doesn't matter...  

As Tobias said, the 32k limit only applies to the wide version of
functions that have appropriately formatted file names, i.e. "\\?\"
prepended to the name, and the expansion means that the actual limit may
be less.  That is, of course, assuming the underlying file system
supports it, otherwise it might still be 260 characters.  The cynical
part of me is also wondering whether it really is 32k characters, or 32k
bytes, in which case the coding may influence the available length.

It looks like the best that can be done is to have our own #define of
32768, use the wide character version of the functions and hope for the

Just to add to my frustration, it looks like the gcc version of stat()
handles timezones properly, while the mingw version doesn't.  Grrr...
(If anyone happens to know something here, please tell me).


More information about the Vm-dev mailing list