Date: Sun, 7 Mar 2010 21:31:39 +0300 From: Andrey Chernov <ache@nagual.pp.ru> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.ORG, Jaakko Heinonen <jh@FreeBSD.ORG>, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG Subject: Re: svn commit: r204803 - head/usr.bin/uniq Message-ID: <20100307183139.GA50243@nagual.pp.ru> In-Reply-To: <20100308015926.O11669@delplex.bde.org> References: <201003061921.o26JLv36014114@svn.freebsd.org> <20100307104626.GA9015@a91-153-117-195.elisa-laajakaista.fi> <20100308015926.O11669@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 08, 2010 at 02:17:41AM +1100, Bruce Evans wrote:
> >> 3) Enforce the implied LINE_MAX limit (from POSIX definition of "text file"
> >> and POSIX uniq(1) description).
>
> This seems to enforce a limit of LINE_MAX - 1, since space for the NUL
> terminator is no longer provided. Hopfully there is no buffer overrun
> from this.
{LINE_MAX} _includes_ trailing \n separator according to POSIX, so real
characters count is {LINE_MAX} - 1.
Since we strip \n on read in uniq(1), there is a room for placing \0
appears, so no off-by-1 error.
> by putting the terminating newline in the buffer. The example is also
> bad in using LINE_MAX, since {LINE_MAX} is not necessarily constant.
> Dynamic allocation is required to use sysconf(__SC_LINE_MAX) and once
> you do that it is almost as easy to support arbitrary line lengths
> like FreeBSD used to.
It is right idea. I'll use sysconf(__SC_LINE_MAX) there.
But currently it does the same (sysconf.c):
case _SC_LINE_MAX:
return (LINE_MAX);
> Old versions of FreeBSD didn't have any of the dynamic allocation, or
> the off-by-1 error, or the new (as I remember) error handling of
> aborting for long lines; they silently discarded characters after the
> LINE_MAX'th one.
To add more:
NetBSD uniq grows (contrary, NetBSD comm silently discarding everything
afterwards).
OpenBSD uniq just use fgets with 8192.
GNU uniq grows.
Unrestricted growing can provide problems I already mention in previous
replies.
Silent discarding allows some trick with input and silent wrong handling
of them.
What is more dangerous - very depends on situation.
--
http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100307183139.GA50243>