Re: [musl] C23: other last minute changes

["Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>]

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