svn commit: r204803 - head/usr.bin/uniq

[Andrey Chernov]

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/