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=-2.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 E41D725336 for ; Sun, 3 Mar 2024 01:06:29 +0100 (CET) Received: (qmail 3539 invoked by uid 550); 3 Mar 2024 00:02:40 -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 3503 invoked from network); 3 Mar 2024 00:02:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709424375; x=1710029175; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=o6TqBZpaK9C6aYdD20HMFU3AGsGc7pCfxP/MtI5UqyA=; b=ZLk6bQ9kgOqskGcycF0tKaUez90ztO6dnk9fs4uVMYsJm7GFecpO/Jk1nv2zvEAWre GW4hQqh+r9Ii2fXfYTSHni7arjJ4Ouv4CBwhkMBO2zT2bAPeuAA9J4JbPdHHN9oVREXd f3CHQqs/huDOgBHxrppaA52KDMC0csFU+jjj9yMy/lyXOZbyn26E7YqBDKT89/PdWpM0 kf3APFcWi1l415Co8AWWDvgAJHke6DNfPHX2uXcj/HFXpdlcI2t0JxlOoRxlZO97axPh z6j2Wuh2tRKkHOLBFuDn0VLD+upWJBDOpSC7KSL4lCdVIiseCd8kDYbXBbJjavWM6Zl4 xxFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709424375; x=1710029175; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o6TqBZpaK9C6aYdD20HMFU3AGsGc7pCfxP/MtI5UqyA=; b=H5vrs3zXJWaSo6D9VhrFzEQO4TttZJQIroJXiToqtLjC6yjKqcXTimBwxh8pMRyi9f QCelHS38dqza8JHqtaohULpp5RmOhsPh+ZNAUJcZMJmc7G7g4n1jCzugH24CknIbzG3u Wf4D93CITAyAaQpglxVYvYGoy2/acVH9cjS27VhAoymbNcRy0fjmDPRgzqWoTcMQ3ueS rScemTZ9fIVPCr1vxCn5k2KVutRBxDu2FkdItFzaeWrBiA6zO9MYI2OMgIcTBAcES7p6 RFQcVtSXBSsrylgStU3AcztWyq8ETruBklbg6fifVlBEZiCwU2aVRzxvg5ppQRi6JI9Q U+Uw== X-Gm-Message-State: AOJu0YwhKDVWXfyvvxlIjt18vXCVCRKr5Ampopr5p688CGqF7lSF1tmc zcqs0JTUARb8pMAjSCw80RMYpLIjaUNGFwoIHJIJ3jneBJTv91oYx4mM0in/wdaOZg== X-Google-Smtp-Source: AGHT+IEBTUpKHKlTzAEdb5zInFnvDZ1p9pVc51VhdFm80jSQ49C16mN5Mp2lLkmox//+srUZ2r0YhA== X-Received: by 2002:a05:600c:1910:b0:412:c839:6d2e with SMTP id j16-20020a05600c191000b00412c8396d2emr4279025wmq.38.1709424374773; Sat, 02 Mar 2024 16:06:14 -0800 (PST) Message-ID: Date: Sun, 3 Mar 2024 00:06:11 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: musl@lists.openwall.com, Rich Felker , =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= References: <20240301164621.5d33a464@inria.fr> <20240301163409.GZ4163@brightrain.aerifal.cx> <20240301181004.GA4163@brightrain.aerifal.cx> <20240301205744.38d8ae83@inria.fr> <20240301211732.GB4163@brightrain.aerifal.cx> Content-Language: en-US From: Gabriel Ravier In-Reply-To: <20240301211732.GB4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] adding C23 support On 3/1/24 21:17, Rich Felker wrote: > On Fri, Mar 01, 2024 at 08:57:44PM +0100, Jā‚‘ā‚™ā‚› Gustedt wrote: >>> 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. > That's unfortunate. It's a really huge number of functions that it's > hard to imagine anyone wanting as external rather than inline. > Normally we aim to put everything in independent TUs, but I think here > that might end up overflowing the ar/link command lines or something > if we did it. I agree it's quite a lot, but w.r.t. whether or not it was good to have this in the standard I think it makes sense to have them, for consistency - basically for the same reason why functions like `getc` which were historically macros were changed to be mandated to be visible as actual functions (though a macro definition was still allowed to be present) for the purposes of e.g. taking an address to them. > >> 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. > Ok, so this is going to be one of the slow parts... > >>> - 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.) > Oh, it's standard now? That's very nice! > >>> - 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. > OK, I seem to have forgotten past conversations on this, so I'll see > if I can dig something up. > >>> - 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?) > It's that it follows a DRY principle, and avoids the extra creative > machinery you were trying to do to get warnings/errors to appear in > the right places due to how multiple clauses of _Generic are handled. > > I think the char version might still need _Generic, but it would be a > _Generic outside/in-front-of the call (as a subexpression of the > typeof for the cast) without anything complex inside it. > > Re: "more portable", these are only used conditional on >= C23, in > which case either is available. > > Rich