Re: [musl] printf("%lc", L'\0')

[Rich Felker <dalias@libc.org>]

On Sat, Jun 24, 2023 at 03:21:55PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
> 
> on Tue, 6 Jun 2023 08:43:22 -0400 you (Rich Felker <dalias@libc.org>)
> wrote:
> 
> > On Tue, Jun 06, 2023 at 12:02:15PM +0200, Jₑₙₛ Gustedt wrote:
> > > Hello,
> > > the Austin Group has a bug at
> > > 
> > > 	https://austingroupbugs.net/view.php?id=1647
> > > 
> > > that lead to a (quite late) ballot comment for C23. It seems that
> > > musl is the only implementation here that plays by the book and has
> > > no byte of output at all for this call
> > > 
> > >      printf("%lc", L'\0');
> > > 
> > > All others seem to be more consistent with the other "c" output
> > > formats and print one NUL byte.
> > > 
> > > Are there any feelings if we are going to change this in the sense
> > > as AG proposes?  
> > 
> > Provided the change is to be aligned between POSIX and ISO C, and that
> > all existing historical implementations except musl do the thing
> > that's proposed, I don't think I have any objection to the change.
> > It's a little more work and less elegant on the implementation side.
> 
> In this week's last round of ballot resolution WG14 chose option 1, so
> this change.
> 
> > Is it really confirmed that all historical C implementations, not just
> > all historical POSIX ones, differ from the specification in this way?
> > That seems rather surprising (and amusing that nobody else bothered to
> > read the spec when implementing). It would be nice to make sure
> > they're informed and in agreement on this, if there are any others.
> 
> There was only time to check this for implementation that were there
> (in particular IBM) but WG14 chose to do this regardless of this lack of
> information.

OK, so to be clear, WG14 is making the change proposed in
https://austingroupbugs.net/view.php?id=1647 and changing the standard
to specify that printf("%lc", L'\0') should produce 1 NUL character?

Rich