corrupt output from col(1) -f

[Ingo Schwarze]

Hi,

talking about ancient bugs...

If you call the col(1) utility with the -f option, permitting forward
half-line feeds in the output stream, and the input stream actually
contains half-line feeds in either direction, you end up with corrupt
output, containing meaningless escape-digitnine sequences instead of
the required escape-tab sequences.

   $ hexdump -C half.txt            
  00000000  61 1b 09 62 1b 09 63 0a                    |a..b..c.|
  00000008
   $ col -f < half.txt | hexdump -C 
  00000000  61 1b 39 0d 20 62 1b 39  0d 20 20 63 0a    |a.9. b.9.  c.|
  0000000d

Note how the third character changes from 0x09 to 0x39.

OK to commit the following fix?  Don't worry, it isn't dangerous,
it only changes two *bits*, only a quarter of a byte.


The bug was introduced by the original author, Michael Rendell,
and committed by Keith Bostic on May 22, 1990 (SCCS rev. 5.1).

The following operating systems are affected:

 * 4.3BSD Reno, BSD Net/2, 4.4BSD, 4.4BSD Lite1, 4.4BSD Lite2
 * All versions of 386BSD, NetBSD, OpenBSD, FreeBSD and DragonFly
 * All versions of Debian GNU/Linux and probably many other Linuxes

Yours,
  Ingo


Index: col.c
===================================================================
RCS file: /cvs/src/usr.bin/col/col.c,v
retrieving revision 1.13
diff -u -p -r1.13 col.c
--- col.c       16 Oct 2014 13:45:12 -0000      1.13
+++ col.c       17 Oct 2014 19:24:58 -0000
@@ -350,7 +350,7 @@ flush_blanks(void)
                PUTC('\n');
        if (half) {
                PUTC('\033');
-               PUTC('9');
+               PUTC('\011');
                if (!nb)
                        PUTC('\r');
        }