On 8/31/23 11:35 AM, Eric Blake wrote:
In today's Austin Group call, we discussed the fact that printf(1) has
mandated behavior for %b (escape sequence processing similar to XSI
echo) that will eventually conflict with C2x's desire to introduce %b
to printf(3) (to produce 0b000... binary literals).

For POSIX Issue 8, we plan to mark the current semantics of %b in
printf(1) as obsolescent (it would continue to work, because Issue 8
targets C17 where there is no conflict with C2x), but with a Future
Directions note that for Issue 9, we could remove %b entirely, or
(more likely) make %b output binary literals just like C.

I doubt I'd ever remove %b, even in posix mode -- it's already been there
for 25 years.

But that
raises the question of whether the escape-sequence processing
semantics of %b should still remain available under the standard,
under some other spelling, since relying on XSI echo is still not
portable.

One of the observations made in the meeting was that currently, both
the POSIX spec for printf(1) as seen at [1], and the POSIX and C
standard (including the upcoming C2x standard) for printf(3) as seen
at [3] state that both the ' and # flag modifiers are currently
undefined when applied to %s.

Neither one is a very good choice, but `#' is the better one. It at least
has a passing resemblence to the desired functionality.

Why not standardize another character, like %B? I suppose I'll have to look
at the etherpad for the discussion. I think that came up on the mailing
list, but I can't remember the details.

Is there
any interest in a patch to coreutils or bash that would add such a
synonym, to make it easier to leave that functionality in place for
POSIX Issue 9 even when %b is repurposed to align with C2x?

It's maybe a two or three line change at most.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    c...@case.edu    http://tiswww.cwru.edu/~chet/

  • RFC: changing print... Eric Blake via austin-group-l at The Open Group
    • Re: RFC: chang... Chet Ramey via austin-group-l at The Open Group
      • Re: bug#65... Eric Blake via austin-group-l at The Open Group
        • Re: bu... Stephane Chazelas via austin-group-l at The Open Group
          • Re... Eric Blake via austin-group-l at The Open Group
            • ... Stephane Chazelas via austin-group-l at The Open Group
          • Re... Robert Elz via austin-group-l at The Open Group
            • ... Stephane Chazelas via austin-group-l at The Open Group
              • ... Chet Ramey via austin-group-l at The Open Group
            • ... Robert Elz via austin-group-l at The Open Group
              • ... Chet Ramey via austin-group-l at The Open Group
      • Re: RFC: c... Oğuz via austin-group-l at The Open Group

Reply via email to