* [musl] printf("%lc", L'\0') @ 2023-06-06 10:02 Jₑₙₛ Gustedt 2023-06-06 12:43 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-06 10:02 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-06 10:02 [musl] printf("%lc", L'\0') Jₑₙₛ Gustedt @ 2023-06-06 12:43 ` Rich Felker 2023-06-06 14:07 ` Jₑₙₛ Gustedt 2023-06-24 13:21 ` Jₑₙₛ Gustedt 0 siblings, 2 replies; 8+ messages in thread From: Rich Felker @ 2023-06-06 12:43 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-06 12:43 ` Rich Felker @ 2023-06-06 14:07 ` Jₑₙₛ Gustedt 2023-06-06 14:19 ` Rich Felker 2023-06-24 13:21 ` Jₑₙₛ Gustedt 1 sibling, 1 reply; 8+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-06 14:07 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-06 14:07 ` Jₑₙₛ Gustedt @ 2023-06-06 14:19 ` Rich Felker 2023-06-06 14:29 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2023-06-06 14:19 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-06 14:19 ` Rich Felker @ 2023-06-06 14:29 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 8+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-06 14:29 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-06 12:43 ` Rich Felker 2023-06-06 14:07 ` Jₑₙₛ Gustedt @ 2023-06-24 13:21 ` Jₑₙₛ Gustedt 2023-06-24 17:24 ` Rich Felker 1 sibling, 1 reply; 8+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-24 13:21 UTC (permalink / raw) Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-24 13:21 ` Jₑₙₛ Gustedt @ 2023-06-24 17:24 ` Rich Felker 2023-06-25 7:26 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2023-06-24 17:24 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] printf("%lc", L'\0') 2023-06-24 17:24 ` Rich Felker @ 2023-06-25 7:26 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 8+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-25 7:26 UTC (permalink / raw) Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-06-25 7:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-06 10:02 [musl] printf("%lc", L'\0') Jₑₙₛ Gustedt 2023-06-06 12:43 ` Rich Felker 2023-06-06 14:07 ` Jₑₙₛ Gustedt 2023-06-06 14:19 ` Rich Felker 2023-06-06 14:29 ` Jₑₙₛ Gustedt 2023-06-24 13:21 ` Jₑₙₛ Gustedt 2023-06-24 17:24 ` Rich Felker 2023-06-25 7:26 ` Jₑₙₛ Gustedt
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).