From owner-freebsd-stable  Sat Mar 17 21:43:57 2001
Delivered-To: freebsd-stable@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP id E951337B718
	for <stable@freebsd.org>; Sat, 17 Mar 2001 21:43:54 -0800 (PST)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.2/8.9.3) id f2I5hb398084;
	Sat, 17 Mar 2001 21:43:37 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 17 Mar 2001 21:43:37 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200103180543.f2I5hb398084@earth.backplane.com>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: stable@freebsd.org
Subject: Re: Not only ftpd's problem with ls */../*.....
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>
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:>     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