[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240301181004.GA4163@brightrain.aerifal.cx>
Date: Fri, 1 Mar 2024 13:10:04 -0500
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: adding C23 support
On Fri, Mar 01, 2024 at 11:34:09AM -0500, Rich Felker wrote:
> On Fri, Mar 01, 2024 at 04:46:21PM +0100, Jₑₙₛ Gustedt wrote:
> > Hello,
> > as you might have heard, C23 has been finally approved by the C
> > committee in January 2024 and is now in the loop with ISO to be
> > published mid-2024. There have been no surprises since the last time
> > we talked, so all patches that I already proposed some time ago should
> > still be valid. They can still be found at
> >
> > https://forge.icube.unistra.fr/icps/musl/-/branches
> >
> > The latest is branch c23-v9 based on today's release of musl, but this
> > will hopefully be updated when we go along. The patches should be
> > stacked from the least debated to some which perhaps will never make
> > it into musl. So if they could be considered bottom-up for inclusion,
> > that would be great.
> >
> > As far as I can see my patches cover most what is needed for C23
> > library support, with one noticeable exception which are functions for
> > <math.h>. These are really too much for me and my level of
> > expertise. But I have seen that Paul Zimmermann has some of them (the
> > π functions) in his project, so this could maybe be covered from
> > there.
> >
> > Compilers are now basically there, gcc-14 and clang-18 have most what
> > is needed for C23 from POV of the language.
>
> Great! Thanks for following up. I was just thinking about trying to
> get C23 additions integrated as a main focus point for the newly
> started release cycle. I'll take a look at your repo and follow up
> with comments.
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)
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.
- 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.
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?
- 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?
- I don't understand the __STDC_VERSION_*_H__ macros. Are these a
requirement of C23, and if so, what are the rules for the values?
I'm not sure if it makes sense to use these as the inclusion-guards
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.
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 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.
- 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.
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.
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.
