[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2023 10:19:19 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: printf("%lc", L'\0')
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
