Date: Sat, 17 Mar 2001 22:29:18 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, stable@freebsd.org Subject: Re: Not only ftpd's problem with ls */../*..... Message-ID: <20010317222918.B82645@prism.flugsvamp.com> In-Reply-To: <200103180027.f2I0RSn96769@earth.backplane.com> References: <local.mail.freebsd-stable/200103172107.f2HL7Ea02611@cwsys.cwsent.com> <200103172253.f2HMrZ008412@prism.flugsvamp.com> <200103180027.f2I0RSn96769@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 17, 2001 at 04:27:28PM -0800, Matt Dillon wrote: > :Yes, I'm considering the following: > : > : gl_flags |= GLOB_MAXFILES > : gl_match = filemax > : > :Since gl_match is only used as an input parameter at the moment. > :Another approach is to limit the number of bytes returned to ARG_MAX, > :but I somewhat dislike that; it makes more sense to me to specify the > :number of paths instead. > :-- > :Jonathan > > Hmm. Well, I like the idea of adding a flag to glob_t->flags but I > would prefer not to add another element to the glob_t structure > that would make it incompatible with existing programs. Remember the > mess changing FILE caused. Whups, the above was a typo, it should have been "gl_matchc". If you check the code, you will find that this field is already there, and used only as an output parameter. (Bah, I must have been really tired when I wrote the original paragraph, that's two mistakes). This means that there will be no backwards compatability problems and we don't have to change the structure size. > How about a combination of glob_t->flags and a global limit that can > be set with a new api call, setgloblimit()? Or perhaps even just > have the setgloblimit() API call and don't even bother with a new flag. I would think a better idea is to have the system default to a hard limit, and then allow those programs that know better to override it. This way, we catch most naive uses of glob, while allowing those users who actually want to iterate over more paths to continue. You'll also note that the glob interface explicitly allows continuing from a previous match (which is what gl_pathc is for), so this fits in nicely. The only additional change I can think of is to add a new error return to explicitly alert the user that the match limit was hit. Doing it this way also negates the need for a setgloblimit. > Remember when csh had an arbitrarily limit on command line length? > Things like 'foreach i ( `find . -type f` )' would fail arbitrarily. > Tcsh fixed that problem. Whatever we do, we do not want to reintroduce > this same sort of problem in other programs (whether shells do their own > globing or not). FYI, it seems that csh (and tcsh) use their own copy of glob, for reasons having to do with memory allocation. This copy will be getting a limit of ARG_MAX, from the last email that I've seen from Christos. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010317222918.B82645>