From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20550 invoked from network); 24 May 2023 14:11:17 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 May 2023 14:11:17 -0000 Received: (qmail 5188 invoked by uid 550); 24 May 2023 14:11: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 5150 invoked from network); 24 May 2023 14:11: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; bh=rtBtZm41Lh/Io4l3E8y/U8cEjgZfW5icbzXuJCxutWs=; b=t6orbqV910BbTDfwt0umkkdKYUJrFGvJ4gqG/QPxy1ujMufBMfCpYogq d8DXpCRrqACvk5rTB4hSzYXs866o7/upc8xkX2zcgaP5GYDspsZ54dQRH 1peOaRkXCTyn0sQ4fOJmFMaiQS2kY3rITIyaLbsaQQVxgJ/vBoI49et5r I=; Authentication-Results: mail2-relais-roc.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.00,189,1681164000"; d="scan'208";a="109480181" Date: Wed, 24 May 2023 16:11:01 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230524161101.785c148f@inria.fr> In-Reply-To: <20230524135837.GU4163@brightrain.aerifal.cx> References: <20230524135837.GU4163@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: multipart/signed; boundary="Sig_/+esaVrGEFrKH+7SJ7z+XuyQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] [C23 feature tests 0/6] tests needed for C23 interfaces --Sig_/+esaVrGEFrKH+7SJ7z+XuyQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Wed, 24 May 2023 09:58:37 -0400 you (Rich Felker ) wrote: > On Wed, May 24, 2023 at 12:04:34PM +0200, Jens Gustedt wrote: > > C23 has some new features, in particular attributes, that are > > prescribed for certain headers. > >=20 > > Jens Gustedt (6): > > C23: provide fallbacks for the use of C attributes > > C23: add a feature test for the __VA_OPT__ feature > > C23: add a feature test for the [u]int128_t > > Add a feature test for the _BitInt types. > > add a `__inline_or_static` macro for pre-C99 compilers > > C23: add an internal interface for the new unsequenced attribute > >=20 > > include/features.h | 51 > > +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 50 > > insertions(+), 1 deletion(-) > >=20 > > --=20 > > 2.34.1 =20 >=20 > I don't see a motivation for any of the patches in this series. sure, you don't have the usage side yet, please be patient I decided to group them together, because they are the easiest applied at the beginning. > For the ones which test for compiler features, musl does not use any > of these features internally, so it does not have any use for > testing for their support. > At the public header level, they're only to be used in > things which are C23-only, and can just be used unconditionally in the > C23-only macros that need them. These are not macros that need them, but functions. C23 requires changes from `_Noreturn` to `[[noreturn]]` for example, deprecates functions and stuff like that. > For __noreturn, we already have _Noreturn (just above your new > definition in the patch). I'm not clear on what the motivation for > having a new alternative to this is. `_Noreturn` remains a keyword for C23, but the headers are required to use the new attribute. So we have to use a new name for the interfaces that can be mapped to the old or new feature according to the needs. > I don't see how __inline_or_static makes sense at all. (Non-static) > inline has very different semantics from static sure > and they cannot be used interchangibly as a "use whichever the > compiler supports". This macro is only meant to make a difference for pre-C99 compilers, which we still seem to support. > We do not use non-static inline at all in musl, > and I'm not aware of any place it would be useful in the public > headers. This comes in later, obvious. 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 :: --Sig_/+esaVrGEFrKH+7SJ7z+XuyQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZG4a9QAKCRAP0+hp2tU3 4stYAJ0Y2bRZLUPD2A533z9zVFuXbC9wrwCeKoTDqPQ0fM23AjdMBKED/LiEhdI= =9FPC -----END PGP SIGNATURE----- --Sig_/+esaVrGEFrKH+7SJ7z+XuyQ--