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

Ben Coman btc at openinworld.com
Mon May 15 17:28:52 UTC 2017


On Mon, May 15, 2017 at 10:31 PM, Eliot Miranda <eliot.miranda at gmail.com> 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?

I couldn't find one.

>  Which APIs have a 32k limit and which have a 260 limit?

fopen() seems to have a 260 limit.
_wfopen()  "might"  have a higher limit, but is unclear and I think
also non-portable.

In this particular case where the VM seems to be output a debug log,
maybe we don't need to consider too much the longer file limit.

Actually looking more closely at print3Dlog() in sqOpenGLRenderer.c
there seems potential for a crash when strlen(getImageName()) equals
PATH_MAX - 2.

So perhaps something more dynamic would be useful anyway...
    char *fileName;
    getImageName = interpreterProxy->ioLoadFunctionFrom("getImageName", "");
    if (!getImageName)
        imageName = "./";
    else
        imageName = getImageName();
    filename = malloc(strlen(imageName) + strlen("Squeak3D.log") + 1);
    strcpy(filename, imageName);
    strcpy(slash ? slash + 1 : fileName, "Squeak3D.log");)
    logfile = fopen(fileName, "at");
    free(filename);
    if (!logfile) {....

i.e. If you can't solve the problem, change the problem.

>
> [why are C APIs such a mess?]

Maybe the comment below the dotted line...
https://cygwin.com/ml/cygwin/2004-10/msg01330.html


cheers -ben


More information about the Vm-dev mailing list