[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240301205744.38d8ae83@inria.fr>
Date: Fri, 1 Mar 2024 20:57:44 +0100
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: adding C23 support
Rich,
that was quick!
on Fri, 1 Mar 2024 13:10:04 -0500 you (Rich Felker <dalias@...c.org>)
wrote:
> Summary of definitely-welcome functionality-changes:
>
> - exposing existing functions that are now baseline C standard:
> timegm, gmtime_r, localtime_r, memccpy, strdup, strndup
>
> - exposing call_once in stdlib.h
>
> - WIDTH macros (for supported types)
>
> - free_sized and free_aligned_sized (the latter should probably assert
> alignment and these could be wired up to check size, but that can be
> done later and is more delicate with how malloc replacements work)
>
> - memalignment
>
> - strfrom[dfl]
>
> - c8 interfaces
>
> - nullptr_t
>
> - timespec_getres
>
> - printf/scanf b/B, wN/wfN (for supported types)
>
> - const-safety macros (but see below)
That would be great!
> And things that can clearly be deferred or omitted:
>
> - changes to make musl itself compile as C23. This is a separate task
> from making musl provide a C23 environment, and much lower priority,
> so I'd like to put it out-of-scope for now.
If you like. But AFAIR these are really no big deal, typing function
pointers correctly and stuff like that. These kind of things that
never get high priority but should be dealed with some day ;-)
> - everything [u]int128_t. This is also out-of-scope; it could at some
> point in the future be considered for whether it makes sense to
> support, but it's not a requirement for C23.
sure, after the last discussions I expected as much. I'll just keep
them on top, so nothing else depends on them.
> Some questions:
>
> - Do the final stdbit.h interfaces require external functions, or is a
> header-only implementation acceptable? Has anything changed on these
> we need to be aware of?
Yes, these require all external functions, besides for the tg
interfaces.
I think I have changed things since we last discussed, because I (and
I was joined by many on the C committee ;-) had misunderstood some of
the interfaces, which direction the bit count went and stuff like
that. A thorough review would be necessary and appreciated.
> - Your stdckdint.h is header-only and is basically just a wrapper for
> gcc/clang builtins. If this is the case, does it make sense for it
> to be supplied by libc at all rather than by the compiler?
For modern compilers it definitively would make sense. But it is an
important step to make these interfaces portable, all this discussion
on making C safer on integer overflow.
So it would probably also good to have them independently from C23
even for old compilers that have the builtins. Then a simple check
with `__has_include` would make them available for everybody.
I have the impression that these interfaces reach far back in history.
A difficulty to make them testable at library-compilation time by
tooling is that they don't depend on the compiler with which the C
library is compiled but on the compiler that the application has in
hand when compiling their code.
(`__has_include` is also in C23 but has been around since ages, so
this provides cheap test for people to see if an interface is
provided.)
> - I don't understand the __STDC_VERSION_*_H__ macros. Are these a
> requirement of C23,
yes
> and if so, what are the rules for the values?
the final values are all `202311L`. They are meant to dissociate from
the C version that the compiler provides and provide means to test for
the presence of particular parts of C23 library support. So C
libraries can improve step by step. For example you could upgrade the
macro for <stdio.h> as soon as its ready, and do <math.h> much later,
or people could even have libmath provided from somewhere else.
> I'm not sure if it makes sense to use these as the inclusion-guards
That was your idea, really ;-)
> if it might make sense to define them with varying values depending
> on feature profile; in that case, it might break optimization
> against multiple-include. However we end up doing these I'd probably
> like to make one clean commit converting all the headers to the same
> approach at once, rather than mixing it with other changes.
I'd really advise against that. It is really meant to be on a per
header base, that's why there are so many of them. In particular,
<math.h> is really a large piece of work, that could delay us for
months or even years.
> Some proposed changes:
>
> - strfroml admits a simpler approach without parsing/converting the
> precision, as described in the previous thread on it (after dropping
> leading zeros, just limit the number of digits).
>
> - assert changes as written are C89-incompatible (no _Bool, and
> strictly speaking __VA_ARGS__, although I think compilers in
> practice have supported it going way back). New assert should
> probably be conditional on C23+ or tweaked to be more compatible
> with older compilers/language versions.
I'd have to look into both of these, that's too long ago.
(And my knowledge basically only starts at C99.)
> - I think all the const-safe macro things admit a solution that
> doesn't repeat the call or require const-casting hacks, and that may
> not even need _Generic, just using a cast on the return value with
> typeof, ala:
>
> #define memchr(p,c,n) ((typeof(1?(p):(void *)1))memchr(p,c,n))
>
> It looks like char/void issues make the str* ones a little bit
> tricker but I think they ultimately admit the same approach.
Yes, maybe, I'll look into these, too.
(And so you think that `typeof` is more portable than generic? Or is
it just that this is simpler?)
> - As discussed before, the printf wN/wfN length prefixes fit within
> the existing state machine, without needing added code. I think I
> posted a draft patch for this.
yes, feel free to use your's and drop mine. But at the time I was not
completely convinced that you'd cover all the cases. In any case,
these specifiers probably need a lot of unit tests.
I'll adapt what I have on top (which are only the 128 things, anyhow,
I think)
> Overall strategy:
>
> Let's start with getting uncontroversial things that are mostly
> standalone (no dependencies on other changes) mergeable/merged, so
> that what's left can be narrowed down. I'll start going through the
> first list above and see what looks mergeable without changes or with
> only trivial changes.
That sounds good!
Thanks
Jₑₙₛ
--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
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.
