Date: Fri, 4 Feb 2005 23:14:05 +0000 From: fergus <fergus@cobbled.net> To: Mario Hoerich <lists@MHoerich.de> Cc: freebsd-bugs@freebsd.org Subject: Re: bin/77031: [patch] comm(1) unable to handle lines greater than LINE_MAX (2048) Message-ID: <20050204231405.GD9766@eyore.cobbled.net> In-Reply-To: <20050204201622.GA29998@Pandora.MHoerich.de> References: <200502040930.j149UQDc043307@freefall.freebsd.org> <20050204201622.GA29998@Pandora.MHoerich.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04.02-21:16, Mario Hoerich wrote:
[ .. ]rgus Cameron:
> Ok, I must admit your patch _is_ far easier on the malloc(3)
> side than the one I posted to -current a while back. I've
> briefly considered to rewrite it, but since your's was the
> only feedback I got (thanks btw) there's probably not much
> interest in my solution anyway. Oh well.
personally i think you should post it 'as is' even if you
don't think it's worth putting extra effort into. the neater
reference is good to have in the PR.
> In addition to that, how does fgetws_a() cope with files, which
> have no '\n' in their last line? (They should of course, but every
> once in a while some file has not.) I might be wrong here, but
> it seems the do { ... } while (line_p) doesn't terminate properly
> in that case. Just scanning through though, might have missed
> something.
that is the only case it terminates at. i think my comments
must be ill concieved because the comment directly above
states
"... stop at EOF (nb: will break from loop at end of line)"
in otherwords the loop will not exit until an EOF (and no
newline - which is standard in my tests). the program will
'break' (line 385) the loop on an EOL.
--
: fergus cameron : [ .] cobbled :
: ^^^^^^@cobbled.net : [ ~][ ] .net :
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050204231405.GD9766>