Date: Sat, 17 Mar 2001 21:43:37 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: stable@freebsd.org Subject: Re: Not only ftpd's problem with ls */../*..... Message-ID: <200103180543.f2I5hb398084@earth.backplane.com> References: <local.mail.freebsd-stable/200103172107.f2HL7Ea02611@cwsys.cwsent.com> <200103172253.f2HMrZ008412@prism.flugsvamp.com> <200103180027.f2I0RSn96769@earth.backplane.com> <20010317222918.B82645@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
Imposing a limit by default is no better then having the hard limit as
a default in the first place. The goal of this fix should be to be as
non-intrusive as possible. Having a hard limit by default is extremely
intrusive. It would be almost as bad as putting a hard limit in, say,
'find'. You don't know *what* type of program will be using the
interface. Just because someone can D.O.S. ftpd doesn't mean that
you should suddenly impose an arbitrary limit on every single program
that might use the interface. Nor would it be appropriate to impose an
additional burden on the programmers using the interface to require them
to explicitly turn off the hard limit if they don't want it... that is
a terrible default API for something like glob! It immediately imposes
the arbitrary limit on every single program using the interface... a limit
that the programmers using the interface probably assume doesn't exist.
It makes to try to protect programmers from themselves a little, but
it doesn't make sense to pollute the functionality and scaleability of
the default interfaces to reach that end. We shouldn't be trying to
protect idiots from themselves... let them learn the hard way so the
rest of us can use these APIs without having to go through loops with
flags and options to make them act the way we want them to act.
Imagine what would happen if, say, the shell imposed an arbitrary limit
on backticked expansions. Oh, I forgot... csh *DID*. And it caused no
end of trouble to people trying to use it to backtick find's and such.
A lot of us wound up using tcsh long before it became in vogue precisely
because tcsh fixed those idiotic limitations. Well, glob() is the same
issue.
-Matt
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?200103180543.f2I5hb398084>