Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

    Date:        Wed, 6 Sep 2023 11:03:25 -0500
    From:        Eric Blake <eblake@redhat.com>
    Message-ID:  
<krlx3gbmizjfmzyzyegeiqrrxqnpkcx7borgddfupduc3p4tkh@eqcqbvs6cewd>

  | If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
  | between printf(1) and printf(3).

Yes.

  | If we reach out to all developers now, we can start the discussion,

That would be reasonable, but shoving wording in the draft standard,
more or less at the last minute, is not the way to accomplish that.

  | - Do nothing; printf(1) and printf(3) have incompatible %b

Since that is the only sane outcome here (one caveat below excepted)
and doesn't require I8 to list %b as deprecated to do it, seems like
it would be better not to do that.

  | - Declare that %b has implementation-defined behavior (shell authors
  |   have the choice on whether %b has old or new behavior)

That's a horrid suggestion, no-one would (should) support that.

  | - Declare that %b is no longer standardized (but implementations can
  |   still provide it as an extension, using their choice of behavior)

We could do that, but what would be the point - just avoiding having
a "conflict" in the standard between printf(1) and printf(3).   Who cares?
We already have one of those with %c and no-one seems to mind (but should,
as fixing that one would actually be useful).

  | - Standardize %#s to do the same thing as %b used to do

We could do that in I9, but that doesn't require deprecating %b.
Of course, if %b remains, there's no point, and it isn't really a
good idea anyway.

  | - Standardize 'printf -c %b 1' which parses its format string
  |   according to C23 rules (output "0b1"), while 'printf %b 1' remains
  |   the old way (output "1")

That one is actually a reasonable suggestion, for any implementation
which feels like it should have a way to make %b output binary numbers
(if someone has an actual need for that, and there isn't a better way
in the meantime).   Any implementation can do that at any time, and it
could be added in I9 if there's support for it (actual implementations
doing it) - and doesn't need %b (the old one) to be deprecated.   This
is just new functionality - initially outside the realm of the standard,
as -c isn't a defined option flag, so implementations can use that to
change the operation any way they like - and it is simply new functionality
for posix if it is deemed worth of incorporation into I9 (or something later).


The only rational one of you options for what to do, which seems fairly
comprehensive, which requires is the one which simply remove

  | But for that work, Issue 8 has to do something - it marks %b
  | obsolescent, merely so that we have the option (not the mandate) to
  | change its behavior in the future.

The only rational one of you options for what to do, which seems fairly
comprehensive, which requires %b listed as obsolescent is the one which
simply removes %b from the standard.

Should that ever happen, you can expect a bug report asking for %b to be
added to the standard the next day (in the form it currently has) - as it
is universally supported (all implementations), and widely used by
applications - it meets all of the requirements for a new feature to be
added.   So you can remove it in D1 of I9, but it will just be back again
in D2.   What would be the point?

  | It may turn out that there is
  | enough resistance that the answer is no change to behavior,

That has already happened, no-one is going to remove %b as it now is.
That means, that apart from the possibility of adding an option to
alter its meaning (like your -c suggestion - though I'd probably suggest
-b for binary 'b' rather than linking it to C printf(3)) there is no
point at all making %b obsolete in I8.   It is already clear that is
never going to happen.

  | Adding %#s as a synonym to %b seems easy enough to do,

It is, but it is not really safe, and as I indicated in the previous message,
there is a better use for %#s we could invent (perhaps) if we're willing
to either gamble that the C people won't define a meaning for it, or
without having any idea what that meaning might be, we're willing in
advance to ignore their definition (assuming there is one someday) and
go our own way.   I don't think that's a good idea, so I have decided
I won't be doing that.   If I though there might be a reason to make
an alias for %b (which I don't), I'd use %p instead, that one is safe.

  | what Issue 9 decides to do to %b, so the Austin Group mentioned that
  | as a non-normative idea in the wording for Issue 8.

I wouldn't even hint at it in the standard.

kre