GNU bug report logs - #65659
RFC: changing printf(1) behavior on %b

Previous Next

Full log

View this message in rfc822 format

From: Stephane Chazelas <stephane <at> chazelas.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 65659 <at> debbugs.gnu.org, bug-bash <at> gnu.org, austin-group-l <at> opengroup.org
Subject: bug#65659: RFC: changing printf(1) behavior on %b
Date: Fri, 1 Sep 2023 07:13:36 +0100

2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> 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).
[...]

Is C2x's %b already set in stone?

ksh93's printf (and I'd  expect ast's standalone printf) has
%<width>[,<precision>[,<base>]d to output a number in an
arbitrary base which IMO seems like a better approach than
introducing a new specifier for every base.

$ printf '%..2d\n' 63
111111
$ printf '0b%.8.2d\n' 63
0b00111111
$ printf '%#.8.2d\n' 63
2#00111111

The one thing it can't do though is left-space-padding of 0b1111.

printf %b is used in countless scripts especially the more
correct/portable ones that use it to work around the portability
fiasco that is echo's escape sequence expansion. I can't imagine
it going away. Hard to imagine the C folks overlooked it, I'd
expect printf %b to be known by any shell scripter.

-- 
Stephane

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.