[musl] C23: other last minute changes

[musl] C23: other last minute changes

[Jₑₙₛ Gustedt]

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

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

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

There are also

   - `mktime` and `timegm` are not supposed to change `tm_wday` if the
     conversion fails

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

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] C23: other last minute changes

[Rich Felker]

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

Re: [musl] C23: other last minute changes

[Jₑₙₛ Gustedt]

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

Rich,

on Sun, 25 Jun 2023 11:24:44 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> 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 explicit specifiers now all have phrases such as

    (the argument will have been promoted according to the integer
    promotions, but its value shall be converted to signed char or
    unsigned char before printing);

Note the shall, here. AFAIKS musl already satisfies that requirement
for the length modifiers for the standard types.

The last minute change only concerns the `PRI` macros. Here a
not-so-brillant phrase has been added that a conversion to the
expected type (so generally `[u]int_leastN_t`) is also expect to
happen when using the `PRI` macros.

It seems that musl here has no length modifiers for narrow types in
the `PRI` macros. I guess that this is relatively easy to fix by
adding `__PRI8` and `__PRI16` auxiliary macros. (Maybe the "fast"
types need something special?)

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

great

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

I did not understand all the code, but it looks ok to me. (I miss
where `errno` would be set, but this is probably in one of the
functions that are called?)

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