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.7 required=5.0 tests=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 19409 invoked from network); 24 May 2023 13:58:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 May 2023 13:58:53 -0000 Received: (qmail 27755 invoked by uid 550); 24 May 2023 13:58:50 -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 27716 invoked from network); 24 May 2023 13:58:49 -0000 Date: Wed, 24 May 2023 09:58:37 -0400 From: Rich Felker To: Jens Gustedt Cc: musl@lists.openwall.com Message-ID: <20230524135837.GU4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 feature tests 0/6] tests needed for C23 interfaces 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. > > 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 > > include/features.h | 51 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 50 insertions(+), 1 deletion(-) > > -- > 2.34.1 I don't see a motivation for any of the patches in this series. 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. 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. I don't see how __inline_or_static makes sense at all. (Non-static) inline has very different semantics from static and they cannot be used interchangibly as a "use whichever the compiler supports". 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. Rich