Re: [musl] C23: other last minute changes

[Rich Felker <dalias@libc.org>]

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