Anybody know why col is segfaulting in OpenBSD?

[flfederation]

More of a curiosity than a problem, though after I amused myself with ASCII 11 someone suggested I pipe it to col (without parameters) and they didn't seem to experience this. When they do it, it simulates tac (which I'm doing instead by piping to tr and rev).

This is running in xterm:

$ printf "hello\vhello"
hello
     hello

$ echo "hello\vhello"
hello
     hello

$ printf "hellohello" | col
hellohello

$ echo "hellohello" | col
hellohello

$ printf "hello\vhello" | col
Segmentation fault

$ echo "hello\vhello" | col
Segmentation fault

[jggimi]

Hello, and welcome!

The vertical tab in col(1) is defined as '\013', not '\v'. If you change the definition to \v, the program no longer segfaults.

diff --git a/usr.bin/col/col.c b/usr.bin/col/col.cindex c3c51b4c630..bd3d5049ca1 100644

--- a/usr.bin/col/col.c
+++ b/usr.bin/col/col.c
@@ -49,7 +49,7 @@
 #define        ESC     '\033'          /* escape */
 #define        SI      '\017'          /* shift in to normal character set */
 #define        SO      '\016'          /* shift out to alternate character set */
-#define        VT      '\013'          /* vertical tab (aka reverse line feed) */
+#define        VT      '\v'            /* vertical tab (aka reverse line feed) */
 
 /* build up at least this many lines before flushing them out */
 #define        BUFFER_MARGIN           32

[flfederation]

So you're saying OpenBSD's col doesn't support https://en.wikipedia.org/wiki/Portable_character_set?

I'm a big fan of OpenBSD as BSD's go, I'm not interested in trolling them-- this is surprising though.

As I said, this is not a real problem for me-- I rarely use col (every couple years or so) and I can certainly work my way around this. Should I email them? Also I would assume \v to be a single character via STDIN before col even got to parse it, but I don't compile C code a lot. No expertise with this. Your diff suggests that \v and \013 are different things-- at some stage they are obviously, but I'm surprised col isn't receiving it as a single octet (or single UTF-8 character). STDIN is more raw a stream than I thought.

Oh! Found this in the man pages:

In the input stream, col understands both the escape sequences of the
form escape-digit mandated by Version 2 of the Single UNIX Specification
("SUSv2") and the traditional BSD format escape-control-character. The
control sequences for carriage motion and their ASCII values are as
follows:

escape-bell Reverse line feed (27 then 7).
escape-digit-7 Reverse line feed (27 then 55).
escape-backspace Half reverse line feed (27 then 8).
escape-digit-8 Half reverse line feed (27 then 56).
escape-tab Half forward line feed (27 then 9).
escape-digit-9 Half forward line feed (27 then 57). In --ff mode, this
sequence may also occur in the output stream.
backspace Moves back one column (8); ignored in the first column.
carriage return (13)
newline Forward line feed (10); also does carriage return.
shift in Shift to normal character set (15).
shift out Shift to alternate character set (14).
space Moves forward one column (32).
tab Moves forward to next tab stop (9).
vertical tab Reverse line feed (11).

All unrecognized control characters and escape sequences are discarded.

Wild. Still not entirely clear how "All unrecognized control characters and escape sequences are discarded" becomes a segfault though. That's not a bug?

[jggimi]

It's a bug. It is not clear to me where the fault lies, because I have not examined the running code. I can see from a core dump that it occurs at col.c in line 327 { lines = l -> l_next }, in the flush_lines() function.


Yes, I believe you should report it. See http://www.openbsd.org/report.html for reporting guidelines.

[flfederation]

Sweet! Thanks.

Update: I'm now told this is common among BSDs, all the way back to 4.x. -- a bug in col handling lines that don't contain \n in them. Someone has submitted a patch and expects it to make its way into OpenBSD, so maybe a bug report isn't needed. But this is more recent than opening this thread, otherwise I would have skipped it.

[ibara]

You should still send an email to bugs@
Don't wait for someone else.