On Fri, Jan 16, 2009 at 7:04 AM, Kostas Georgiou <k.georg...@imperial.ac.uk> wrote: > On Thu, Jan 15, 2009 at 01:41:53PM -0700, Brad Nicholes wrote: > >> >>> On 1/15/2009 at 8:56 AM, in message >> <496efa2a020000ac0003a...@lucius.provo.novell.com>, "Brad Nicholes" >> <bnicho...@novell.com> wrote: >> >> After taking a little closer look at the patch, I think we are OK as >> far as the recursive call to process_path() is concerned since this >> case is an error condition and should stop processing rather than >> continuing in the recursive loop.
indeed, this should work just fine. >> The other two concerns are still >> there however. I still think that we are off-by-one in the malloc >> call. It should be len+1 and I still think that we should limit the >> malloc to 256 rather than allowing it to be unlimited. > > I agree about the off-by-one argh, my bad sorry, double dumb since I even considered the case. len+1 it is and the comment should go, thanks. > but I am not too worried about a malloc > limit, from what I can tell it can only get as high as REQUESTLEN. I agree with Kostas, as I wrote in my initial email I didn't worry about that because of the REQUESTLEN boundary which is enforced in readline. as to limiting the path to 256 I actually did that in my first implementation, but eventually converted to a malloc solution because I was reminded that "640 KB ought to be enough for everybody" and I could see no downsides. > > The malloc call needs to be checked for NULL and the comment that > "The recursive structure doesn't require any memory allocations" is > false now if malloc replaces the stack allocation. correct thanks everybody ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
