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 11:52:29 -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>
- Reply-to: cygwin at cygwin dot com
On Sat, Nov 15, 2003 at 11:45:34AM -0500, Christopher Faylor wrote:
>On Sat, Nov 15, 2003 at 07:07:26PM +1100, Robert Collins wrote:
>>On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote:
>>>Yes, I've already (obviously?) been to SUSv3. I wasn't talking about
>>>standards. I was talking about common practice.
>>>If you have a common practice web site that you want to show me then
>>>that might be a convincing argument. Otherwise, I'll have to fall back
>>>on my personal UNIX experience.
>>Part of a thread on this in another project. Seems like the hurd
>>follows the no-PATH_MAX, use pathconf() always approach. Which means
>>that everything thats portable to the hurd, will Do The Right Thing, if
>>we eliminate the PATH_MAX and MAXPATHLEN defines. In my digging, I
>>found that PATH_MAX, if defined, MUST be the largest path length
>>possible. Presumably thats so that programs with static buffers won't
>>run into trouble.
>I mention "common practice" and you point me at a discussion which talks
>about the Hurd??? The Hurd?????????????????????????????????????????????
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.
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html