[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230625152443.GQ4163@brightrain.aerifal.cx>
Date: Sun, 25 Jun 2023 11:24:44 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: C23: other last minute changes
On Sun, Jun 25, 2023 at 09:48:18AM +0200, Jₑₙₛ Gustedt wrote:
> Hello,
> there were other last minute (in the literal sense of the term)
> changes to C23 that might impact musl. I updated the summary page at
>
> https://gustedt.gitlabpages.inria.fr/c23-library/
>
> As far as I can see these are
>
> - `PRI` macros for narrow types now have to be exact, musl does not
> seem to conform to this new requirement
Yes; this probably requires some minor conditional logic for the FAST
cases but otherwise it should be very straightforward to change. It's
not clear to me what the conformance distinction is here, though. Is
it not undefined behavior to pass an argument for %hhd (for example)
whose value is not in the range of a signed char? Perhaps values in
the range of unsigned char are also supposed to be okay, but should
get interpreted as signed? I don't see where printf is specified to
handle arbitrary wrong-type-but-rank-<=-int values, though..?
> - the `lc` specifier for `printf` does print NUL for a nul
> character, we already talked about this
>
> For the first, a change is conforming to C17 so it can be done
> immediately without problems. The second is in principle a normative
> change in C and in POSIX, but it seems that all other POSIX
> implementations already are doing this, so probably we should just
> fall in line.
Yes, this change can be made immediately. Since actually adding
single-wchar processing code seems like messy duplication of the code
already in the %ls case, my leaning would be just adding this as
(pseudocode since a new label is needed too):
case 'C'
+ if (!arg.i) goto case 'c';
wc[0] = arg.i;
> There are also
>
> - `mktime` and `timegm` are not supposed to change `tm_wday` if the
> conversion fails
My default interpretation (which admittedly we don't *always* follow,
and is difficult or impossible in a few cases) is that, if a function
is specified to modify some pointed-to object on successful
completion, that it's not even allowed to modify it on failure. And
indeed we do not touch *tm until the final success path in
mktime/timegm.
> - `fputwc` now also sets the error indicator of the stream if an
> encoding error occurs. This was previously already required by
> POSIX.
>
> I don't think that musl has problems here
That sounds right. I guess fputwc is still unfixed, though? I probably
should have followed up on that from the Austin Group side..
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.
