[Bug 260016] devel/libtextstyle: calls tputs() with invalid string

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260016

            Bug ID: 260016
           Summary: devel/libtextstyle: calls tputs() with invalid string
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: tijl@FreeBSD.org
          Reporter: adridg@freebsd.org
             Flags: maintainer-feedback?(tijl@FreeBSD.org)
          Assignee: tijl@FreeBSD.org

Created attachment 229695
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229695&action=edit
Patch for ports-tree

When libtextstyle outputs a hyperlink, on terminals that support hyperlinks, it
outputs `\e]8;id=<id-part>;<url-part>;` . The id-part and the url-part are
user-supplied (by the calling program). In a common case where the ID is NULL,
libtextstyle invents one based on a simple hash. On my system, with bison as
calling program, the hash is usually  `5b1...` (32 characters).

Libtextstyle outputs the escape-sequence by calling `tputs()` five times. It
passes e.g. the id-part as a string to `tputs()`. From the tputs manpage, it
seems that only terminal-escape codes should be passed in, or return-values
from tparm(). In any case, when the string passed to `tputs()` starts with a
digit, this is interpreted **on BSDs only** by ncurses as specifying a delay.
The leading digits vanish from the output.

The attached patch replaces the `tputs()` calls with a call to write the
strings to the output stream. This avoids any interpretation of the id-part and
url that `tputs()` might do.

(I would never have noticed, but in combination with bugs in ncurses and
specific terminal settings, this crashes bison; avoiding the ncurses bugs by
patching libtextstyle fixes my bison crashes)

The attached patch applies to the ports-tree; it adds a single patch to replace
tputs in the relevant routing with direct-writes. I suppose this warrants an
exp-run (given the warning in the Makefile) and ought-to-be-upstreamed, but I
don't know how to do the latter.

-- 
You are receiving this mail because:
You are the assignee for the bug.