Project

General

Profile

Bug #9646

printf(1) handles %b badly

Added by Garrett D'Amore about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
cmd - userland programs
Start date:
2018-07-09
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

We are unfortunately not handling the %b specifier correctly in the face of precision or width specifiers. (Why anyone would ever want to use either of those is beyond me.) Further, the precision with behavior is "unspecified" by POSIX (as of 2018), but most implementations seem to have taken it to be treated the same as for "s", applied after the unescaping.

This was noticed by FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229641

History

#1

Updated by Garrett D'Amore about 1 year ago

I have written a draft fix for this, but it will take a while to generate a full and true build for illumos, as I don't have a build system handy at the moment:

@@ -346,20 +346,16 @@
         size_t len;
         char *p;
         int getout;
-        char *bfmt;
-        if (((bfmt = strdup(start)) == NULL) ||
-            ((p = strdup(getstr())) == NULL)) {
+
+        p = strdup(getstr());
+        if (p == NULL) {
             warnx2("%s", strerror(ENOMEM), NULL);
             return (NULL);
         }
-        /* Convert "b" to "s" for output. */
-        bfmt[strlen(bfmt)-1] = 's';
-
         getout = escape(p, 0, &len);
-        PF(bfmt, p);
-
-        free(bfmt);
+        (void) fputs(p, stdout);
         free(p);
+
         if (getout)
             exit
#2

Updated by Garrett D'Amore about 1 year ago

Whoops, that diff is backwards. Anyway, easy enough to see.

Also available in: Atom PDF