This is the mail archive of the
mailing list for the Cygwin project.
Re: For masochists: the leap o faith
On Sat, Nov 22, 2003 at 08:44:49PM +1100, Robert Collins wrote:
> On Fri, 2003-11-21 at 21:25, Corinna Vinschen wrote:
> > On Fri, Nov 21, 2003 at 07:58:36AM +1100, Robert Collins wrote:
> > > > I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big
> > > > value as, e. g. the same as on Linux, 4096, or even the biggest possible
> > > > plus one: 32768. The latter is probably the better value. So my choice
> > > > is a)
> > >
> > > Ok. What should we set CYG_MAX_PATH to initially then? I think we should
> > > start at 4K, until we've seen whether there are any stack size issues.
> > I think we should get rid of static buffers in most cases. Some of them
> > might be kept in place, returning to MAX_PATH, the others should use
> > another technique, like alloca. As I see it, CYG_MAX_PATH should be just
> > a temporary measure.
> "Stack issues", not static buffers - or did you mean 'stack' buffers?
> Anyway, yes, we should tune each individual thing to an appropriate
> strategy - self managing objects, alloc etc.
> However, CYG_MAX_PATH is simply decoupling the win32 ANSI path limit
> from our internal path limit. If and when we don't have an effective
> internal limit anymore, sure it can go.
Yup, that's what I meant. It doesn't hurt to check the occurences
of CYG_MAX_PATH now, if there isn't a simple way to get around without
it. Other than that, I think the right limit is 32K as I already wrote
in my first reply (see above), not something less than that. Using
some arbitrary number like 4K only results in headaches at a point
where you had never expected it. The difference to Linux is, that 4K
is the real limit on Linux, while our limit is 32K.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:email@example.com
Red Hat, Inc.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html