Date: Thu, 16 Jun 2016 02:29:19 +0530 From: Abhinav Upadhyay <er.abhinav.upadhyay@gmail.com> To: freebsd-hackers@freebsd.org Subject: Possible bug in ul(1) Message-ID: <CAHwRYJ=DeqMmc9mfrOn=CS4JkHLaSU842E2GG=o_EuOQUPehUA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, NetBSD's ul(1) had a bug, where it would dump core for certain inputs containing really long lines. For example, we had two man pages for which it would crash: man evrpc | ul man xdm | ul We had a statically allocated buffer (struct CHAR obuf[MAXBUF]) for representing columns in the lines of the input file, and for really long lines, we would try to read beyond the size of the buffer and crash. We've fixed it by using reallocarr(3) and friends [1]. FreeBSD also uses a statically allocated buffer, but it ensures that it never reads beyond the fixed size of the buffer and therefore doesn't crash for such bad inputs. line 170: while ((c = getwc(f)) != WEOF && col < MAXBUF) switch(c) { However, it stops reading the file just at the point where the number of columns in the line exceeds the buffer size and exits with status 0. I think, if it is not going to read the complete file, it should exit with a non-0 status, so that the user gets to know that the output from ul(1) is not complete? Or, probably it would be better to fix ul(1) so that it is able to read files with arbitrarily long lines. :) PS: I'm not subscribed to the list, so please keep me CC'ed. [1]: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ul/ul.c.diff?r1=1.16&r2=1.17&only_with_tag=MAIN - Abhinav
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHwRYJ=DeqMmc9mfrOn=CS4JkHLaSU842E2GG=o_EuOQUPehUA>