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/
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
