From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 57ACD2505B for ; Fri, 1 Mar 2024 19:10:00 +0100 (CET) Received: (qmail 15884 invoked by uid 550); 1 Mar 2024 18:06:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15846 invoked from network); 1 Mar 2024 18:06:14 -0000 Date: Fri, 1 Mar 2024 13:10:04 -0500 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20240301181004.GA4163@brightrain.aerifal.cx> References: <20240301164621.5d33a464@inria.fr> <20240301163409.GZ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240301163409.GZ4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 > > . 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