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?
'Statically sized' > 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
