Date: Wed, 6 Sep 2023 11:32:32 -0500
From: Eric Blake <ebl...@redhat.com>
Message-ID:
<z7svroub44xygdps6apuikftl4tjtpc67zkq5ivb6cmktsfnfg@5vc4pkemtzog>
| You (anyone reading this, not just kre) are welcome to join tomorrow's
| Austin Group meeting
Thanks, but I don't expect its time of day will coincide with
mine this week, at best I would be a half asleep zombie.
| it is a Zoom call
As best I understand it, zoom does not support NetBSD - which
is the only platform I use, which has been true for decades now
(previously I also used SunOS (not Solaris) and Ultrix).
While probably works on android (ie: phone) meeting use that
way would not be convenient for anyone - certainly not for me
staring at it all the time, and assuming that it works with
video enabled, not for anyone else with an image moving around
randomly... (my phone has no stand, I haven't been able to
find one which fits it).
| Or you can add comments to the bug directly.
I have done that already, and probably will add one more.
| Of course, the gamble is easier to win if we have multiple independent
| implementations that have all coordinated to do it the same way, so we
| can push back on WG14 to tell them they would be foolish to commandeer
| %#s for anything other than what existing practice has.
Which worked how well with %b ?
Further, upon reflection, I think a better use of %#s in printf(1)
(no point in printf(3)) would be to explicity output a string of
bytes (what %s used to do, before it was reinterpreted to output
characters instead). While the two might seem to be mostly the
same, that depends upon the implementation - if an implementation
treats strings of characters as arrays of wchar_t, and converts
from byte encoding to wchar_t on input, there's no guarantee that
the output (converted back from wchar_t to byte encoding) will be
identical to the input string. Sometimes that might not be
desirable and a method to simply copy the input string to the
output, as uninterpreted bytes might be useful to have. To me
that is a better use of %#s than as a %b clone - particularly
as %b needs the same kind of variant (%#b). This also deals
with the precision issue, %.1s is 1 character fr9m the arg
string, %#.1s is one byte instead.
If there were to be anything worthy of announcing as deprecated
from posix printf(1) it would be %c - then we could make %c be
compat with its printf(3) meaning, where it takes a codepoint
as an int (just 8 bits in printf(3) but we don't neet to retain
that restriction) and outputs the associated character, rather
than just being an (almost) alias for %.1s -- where the almost
is because given '' as the arg string, %c is permitted to output
\0 or nothing, where %.1s is required to output nothing. Because
it is unspecified which happens with %c, portable applications
cannot rely upon either behaviour, so %.1s is a much safer and
more portable format to use for the purpose. If %c were
(eventually) altered to take an int (codepoint) as its arg,
rather than a string, we could also stop needing to tell people
they have to use the bizarre printf \\$(printf %o val) nonsense
method to do such a simple operation, which only works for
8 bit codepoints.
kre
