[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 May 2023 09:58:37 -0400
From: Rich Felker <dalias@...c.org>
To: Jens Gustedt <Jens.Gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: [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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
