Skip site navigation (1)Skip section navigation (2)
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>