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

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

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?

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Felker]

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.

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.

Rich

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

Rich,

on Tue, 6 Jun 2023 08:43:22 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> Is it really confirmed that all historical C implementations, not just
> all historical POSIX ones, differ from the specification in this way?

I personnally don't know much more than I posted in my question. AG
tells us that musl is the only one they know about

      we are only aware of one (musl) that obeys a strict reading of
      the C standard.

I don't know about historic implementations evidently.

> That seems rather surprising

It seems they prefer internal consistency over such a boundery case
specification.

> (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.

That will be one of the difficulties with a request that comes in so
late in the procedure. We will have not much data to base our
decision, but for the projects where the WG14 members are implicated
in one way or another.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Felker]

On Tue, Jun 06, 2023 at 04:07:08PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
> 
> on Tue, 6 Jun 2023 08:43:22 -0400 you (Rich Felker <dalias@libc.org>)
> wrote:
> 
> > Is it really confirmed that all historical C implementations, not just
> > all historical POSIX ones, differ from the specification in this way?
> 
> I personnally don't know much more than I posted in my question. AG
> tells us that musl is the only one they know about
> 
>       we are only aware of one (musl) that obeys a strict reading of
>       the C standard.
> 
> I don't know about historic implementations evidently.

The class AG is considering is likely POSIX/POSIXy implementations,
not all C implementations.

> > It would be nice to make sure they're informed and in agreement on
> > this, if there are any others.
> 
> That will be one of the difficulties with a request that comes in so
> late in the procedure. We will have not much data to base our
> decision, but for the projects where the WG14 members are implicated
> in one way or another.

In that case I would probably lean towards asking AG to instead make a
change to (CX shaded) "it is unspecified whether a single zero byte is
written or the conversion has no output" and not imposing a change on
potentially unaware C implementations that have nothing to do with
POSIX, nor imposing a requirement to conflict with ISO C.

I really doubt there is anyone who cares about the specific behavior
in this case, but it seems unprofessional to do something like this
last-minute.

"Future directions" notes could be added that this might change.

Rich

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

Rich,

on Tue, 6 Jun 2023 10:19:19 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> In that case I would probably lean towards asking AG to instead make a
> change to (CX shaded) "it is unspecified whether a single zero byte is
> written or the conversion has no output" and not imposing a change on
> potentially unaware C implementations that have nothing to do with
> POSIX, nor imposing a requirement to conflict with ISO C.
> 

yes that's what they are proposing as a fallback alternative:

    …, except that if the `wint_t` argument is a null wide character
    it is unspecified whether it is converted to no bytes or to a null
    byte.

> I really doubt there is anyone who cares about the specific behavior
> in this case, but it seems unprofessional to do something like this
> last-minute.

indeed

> "Future directions" notes could be added that this might change.

maybe


Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

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.



Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Felker]

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

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

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Rich,

on Sat, 24 Jun 2023 13:24:55 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> 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?

yes

the text that was adopted reads

    If an `l` length modifier is present, the `wint_t` argument is
    converted as if by a call to the `wcrtomb` function with a pointer
    to storage of at least `MB_CUR_MAX` bytes, the `wint_t` argument
    converted to `wchar_t`, and an initial shift state.

Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]