[Top][All Lists]

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

Re: [Gnu-arch-users] Arch On Cygwin(Win32)

From: John Kinson
Subject: Re: [Gnu-arch-users] Arch On Cygwin(Win32)
Date: Mon, 17 Nov 2003 16:52:40 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

I'd been spending some time making the same changes to Cygwin, but gave up when the scale of the task became apparent. Cygwin uses both PATH_MAX and MAX_PATH literals, and the side effects from changing these caused core dumps in other areas. This is a high-risk change to Cygwin, which has already been pointed out.

Having looked at the POSIX spec though, I'm not sure Cygwin should be changed at all. The spec states (see that PATH_MAX should have a Minimum Acceptable Value of _POSIX_PATH_MAX. _POSIX_PATH_MAX is defined by POSIX to be 256.

POSIX also states the following:

    Implementations may choose any appropriate value for each
    limit, provided it is not more restrictive than the Minimum
    Acceptable Values listed below.  Symbolic constant names
    beginning with _POSIX may be found in <unistd.h>.

    Applications should not assume any particular value for a
    limit. To achieve maximum portability, an application should
    not require more resource than the Minimum Acceptable Value
    quantity. However, an application wishing to avail itself
    of the full amount of a resource available on an
    implementation may make use of the value given in
    <limits.h> on that particular implementation, by using the
    symbolic names listed below.


My interpretation of the above is that Cygwin and Windows are perfectly POSIX-compliant in meeting the 256 byte MAV value. In relying on the Linux implementation of PATH_MAX (set in /usr/include/linux/limits.h to 4096, although tla just has 4096 hard coded as a magic value), Tom compromised the portability of arch. I would argue that the correct change is to rework arch to confine itself to the POSIX minimum value.

Even changing the category/branch/version replication would probably not be enough to guarantee that the 256 character limit was not exceeded. A more fundamental restructuring is needed. This is obviously a large change, with backwards compatibility issues, so I wouldn't expect Tom to be willing to do this.

Having said that, if an arch redesign does not occur, then wouldn't it be far safer to implement the hackerlab vu_ calls to use the "W" Win32 directory calls directly, rather than change Cygwin? I just hacked successfully safe_mkdir to call CreateDirectoryW as a proof of concept, and this would seem *much* easier than the Cygwin patch... Any drawbacks to this approach?


Parker, Ron wrote:
 > -----Original Message-----
 > From: Robert Collins [mailto:address@hidden

 > Well, I'm happy for you to shoot over the patches to me as they are.
 > I'll see what they do for me :).

You asked for it.  Here are 5 patches against cygwin 1.5.5-1:

Adds cygwin_create_file and changes all CreateFile references to use

        Ditto for cygwin_create_directory.

        Implement calling CreateFileW and CreateDirectoryW for all local
file system files using the "\\?\" prefix.

        Raise MAXPATH from 260 to 4096.

Diagnostic code for that I used when necessary. It is
even commented out in the diff.


Gnu-arch-users mailing list

GNU arch home page:

What if the Hokey Cokey really _is_ what it's all about?

reply via email to

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