This is the mail archive of the
mailing list for the Cygwin project.
Re: For masochists: the leap o faith
- From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 15 Nov 2003 14:15:00 -0500
- Subject: Re: For masochists: the leap o faith
- References: <3FB4D81C.email@example.com> <3FB53BAE.firstname.lastname@example.org> <20031114220708.GA26100@redhat.com> <3FB55BCE.email@example.com> <20031115044347.GA29583@redhat.com> <1068883645.1109.122.camel@localhost> <20031115164534.GB3039@redhat.com> <20031115165229.GA3296@redhat.com> <Pine.GSO.4.56.0311151259270.922@eos>
- Reply-to: cygwin at cygwin dot com
On Sat, Nov 15, 2003 at 01:09:00PM -0600, Brian Ford wrote:
>On Sat, 15 Nov 2003, Christopher Faylor wrote:
>> Btw, I've moved this discussion here from cygwin-patches because we are
>> talking about a change which could impact a number of people. Robert is
>> submitting patches which increase the maximum path length for NT-class
>> My concern is that PATH_MAX will be increased for this change. It will
>> no longer reflect the win32 api MAX_PATH value and I was wondering if
>> that would cause problems for existing applications.
>Would this affect gcc -mno-cygwin? That would seem bad.
No. It should have no effect. Different header files.
>> I thought the cygwin mailing list would be a wider audience for this
>> type of thing than cygwin-patches, especially since no one is offering
>> opinions in cygwin-patches.
>Well, since your soliciting opinions...
>I don't have much of one other than I'd really prefer to keep
>PATH_MAX/MAX_PATH and define them to the largest allowable path so they
>can still be used for sizing arrays. I don't really care if that lenght
>is not always supported.
Ok. That was one plan. I was concerned that a program might be assuming that
since it had carefully checked that a path was <= PATH_MAX, everything was
fine when on a Windows 98 system, it could conceivably fail.
I know that this isn't exactly a 100% safe and sanctioned use of PATH_MAX but
it seems like the possibility exists that working code could be broken by
Robert seems to be leaning towards removing the PATH_MAX define entirely
>I would assume that any application that goes to the trouble of doing
>something other than bailing with an error in that case should actually
That's the way I'd write my code but I'm not certain that all of the currently
running code is so robust.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html