Date: Thu, 15 Mar 2001 13:25:03 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Jonathan Lemon <jlemon@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen glob.c Message-ID: <20010315132503.D82645@prism.flugsvamp.com> In-Reply-To: <200103151921.OAA48111@khavrinen.lcs.mit.edu> References: <200103151850.f2FIoXl53931@freefall.freebsd.org> <200103151921.OAA48111@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 15, 2001 at 02:21:28PM -0500, Garrett Wollman wrote: > <<On Thu, 15 Mar 2001 10:50:33 -0800 (PST), Jonathan Lemon <jlemon@FreeBSD.org> said: > > > Limit the number of paths that glob can return to MAX_GLOBENTRIES, which > > is currently set to 10000. > > I don't see any language in the current POSIX draft that permits such > behavior. I think it's clearly intended that glob() return all paths > which match the given specification. The only possible error relevant > to this case is: > > GLOB_NOSPACE An attempt to allocate memory failed. > > But I think returning GLOB_NOSPACE for the case of ``you tried to glob > too many files'' is a huge stretch. Well, I agree that there is nothing in the documentation that explicitly limits the amount of space that glob should take, and this is probably a bug. It woule probably be better if somehow, the application set the limit in advance. I'm also returning GLOB_ABEND instead of GLOB_NOSPACE. If you want to try this out, ftp to your machine, and then perform 'ls */../*/../*/../*/../*/../*/../*'; this will cause ftpd to start chewing up all memory and cpu. This applies to anything using glob, not just ftpd, though. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010315132503.D82645>