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.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 3EEE525F1E for ; Fri, 1 Mar 2024 20:57:58 +0100 (CET) Received: (qmail 24109 invoked by uid 550); 1 Mar 2024 19:54:13 -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 24071 invoked from network); 1 Mar 2024 19:54:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5NJStiWOzS1hAlcwFH05jTB4AprMNT5QePurbnqmvWg=; b=EbUrOZk7HH0qYiAxTyj3316UO+AJTz6/iPuWMCMPkQpHeuAAD2/UNWER pzc8Wq/AwcGLSIrJ/31XhloNFeJCQ306MMYaYCP4bUKldUpMF12G4Jb6I HkrN0CZ7iLRn8/bhkOO2dQDRPM4K8ZQF+0ea4HMtCxynj5E9JriAgUBsc 4=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.06,197,1705359600"; d="scan'208";a="81083892" Date: Fri, 1 Mar 2024 20:57:44 +0100 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20240301205744.38d8ae83@inria.fr> In-Reply-To: <20240301181004.GA4163@brightrain.aerifal.cx> References: <20240301164621.5d33a464@inria.fr> <20240301163409.GZ4163@brightrain.aerifal.cx> <20240301181004.GA4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] adding C23 support Rich, that was quick! on Fri, 1 Mar 2024 13:10:04 -0500 you (Rich Felker ) wrote: > Summary of definitely-welcome functionality-changes: >=20 > - exposing existing functions that are now baseline C standard: > timegm, gmtime_r, localtime_r, memccpy, strdup, strndup >=20 > - exposing call_once in stdlib.h >=20 > - WIDTH macros (for supported types) >=20 > - 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) >=20 > - memalignment >=20 > - strfrom[dfl] >=20 > - c8 interfaces >=20 > - nullptr_t >=20 > - timespec_getres >=20 > - printf/scanf b/B, wN/wfN (for supported types) >=20 > - const-safety macros (but see below) That would be great! > And things that can clearly be deferred or omitted: >=20 > - 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: >=20 > - 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 as soon as its ready, and do 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, is really a large piece of work, that could delay us for months or even years. > Some proposed changes: >=20 > - 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). >=20 > - 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: >=20 > #define memchr(p,c,n) ((typeof(1?(p):(void *)1))memchr(p,c,n)) >=20 > 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: >=20 > 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=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::