Date: Sun, 7 Mar 2010 14:52:11 +0300 From: Andrey Chernov <ache@nagual.pp.ru> To: Jaakko Heinonen <jh@FreeBSD.ORG> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG Subject: Re: svn commit: r204803 - head/usr.bin/uniq Message-ID: <20100307115210.GA45796@nagual.pp.ru> In-Reply-To: <20100307104626.GA9015@a91-153-117-195.elisa-laajakaista.fi> References: <201003061921.o26JLv36014114@svn.freebsd.org> <20100307104626.GA9015@a91-153-117-195.elisa-laajakaista.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 07, 2010 at 12:46:27PM +0200, Jaakko Heinonen wrote: > On 2010-03-06, Andrey A. Chernov wrote: > > 3) Enforce the implied LINE_MAX limit (from POSIX definition of "text file" > > and POSIX uniq(1) description). > > Although a file with lines longer than LINE_MAX isn't a text file by > POSIX definition I don't think that POSIX requires uniq(1) to reject > non-POSIX text files. Thus I would like to keep the support for longer > lines. Strictly speaking, POSIX says that uniq(1) (among others) supposed to work with text files. Keeping it working with non-text ones too will be an _extension_, not covered by POSIX. But thinking about your suggestion the question immediately arises: how much "longer lines"? say, up to 6x times? up part of memory avaliable? up to size_t max? etc. Any sort of limit still will remains the limit, but we already have POSIX limit for that. I don't see much sense to replace one limit with the same kind of it, but, say, 2x bigger. Moreover, very big limits will cause security risk easily producing lack of resources (memory). -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100307115210.GA45796>