[musl] [C23 feature tests 1/6] C23: provide fallbacks for the use of C attributes

[musl] [C23 feature tests 1/6] C23: provide fallbacks for the use of C attributes

[Jens Gustedt]

---
 include/features.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/include/features.h b/include/features.h
index 85cfb72a..8e1d84e3 100644
--- a/include/features.h
+++ b/include/features.h
@@ -35,6 +35,26 @@
 #define _Noreturn
 #endif
 
+#ifdef __has_c_attribute
+# if __has_c_attribute(__noreturn__)
+#  define __noreturn [[__noreturn__]]
+# endif
+# if __has_c_attribute(__deprecated__)
+#  define __deprecated [[__deprecated__]]
+# endif
+#endif
+
+#ifndef __noreturn
+# define __noreturn _Noreturn
+#endif
+#ifndef __deprecated
+# if defined(__GNUC__)
+#  define __deprecated __attribute__((__deprecated__))
+# else
+#  define __deprecated
+# endif
+#endif
+
 #define __REDIR(x,y) __typeof__(x) x __asm__(#y)
 
 #endif
-- 
2.34.1

[musl] [C23 feature tests 2/6] C23: add a feature test for the __VA_OPT__ feature

[Jens Gustedt]

---
 include/features.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/features.h b/include/features.h
index 8e1d84e3..05abcadc 100644
--- a/include/features.h
+++ b/include/features.h
@@ -57,4 +57,8 @@
 
 #define __REDIR(x,y) __typeof__(x) x __asm__(#y)
 
+#define __has_VA_OPT2(_0, _1, ...) _1
+#define __has_VA_OPT1(...) __has_VA_OPT2(__VA_OPT__(,) 1, 0,)
+#define __has_VA_OPT __has_VA_OPT1(C23)
+
 #endif
-- 
2.34.1

[musl] [C23 feature tests 3/6] C23: add a feature test for the [u]int128_t

[Jens Gustedt]

---
 include/features.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/features.h b/include/features.h
index 05abcadc..4083436d 100644
--- a/include/features.h
+++ b/include/features.h
@@ -61,4 +61,11 @@
 #define __has_VA_OPT1(...) __has_VA_OPT2(__VA_OPT__(,) 1, 0,)
 #define __has_VA_OPT __has_VA_OPT1(C23)
 
+// If the platform supports the 128 integer type and has _BitInt(N)
+// support where N large enough (all C23 compiler should have the
+// latter)
+#if __SIZEOF_INT128__ && (__BITINT_MAXWIDTH__ >= 128)
+#define __has_int128_t 1
+#endif
+
 #endif
-- 
2.34.1

[musl] [C23 feature tests 6/6] C23: add an internal interface for the new unsequenced attribute

[Jens Gustedt]

---
 include/features.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/features.h b/include/features.h
index 5d460800..f65d5b4d 100644
--- a/include/features.h
+++ b/include/features.h
@@ -46,6 +46,9 @@
 # if __has_c_attribute(__deprecated__)
 #  define __deprecated [[__deprecated__]]
 # endif
+# if __has_c_attribute(__unsequenced__)
+#  define __unsequenced [[__unsequenced__]]
+# endif
 #endif
 
 #ifndef __noreturn
@@ -58,6 +61,13 @@
 #  define __deprecated
 # endif
 #endif
+#ifndef __unsequenced
+# if defined(__GNUC__)
+#  define __unsequenced __attribute__((__const__))
+# else
+#  define __unsequenced
+# endif
+#endif
 
 #define __REDIR(x,y) __typeof__(x) x __asm__(#y)
 
-- 
2.34.1

[musl] [C23 feature tests 5/6] add a `__inline_or_static` macro for pre-C99 compilers

[Jens Gustedt]

pre-C99 may not have `inline`. To be able to emulate `inline` for
those compilers we use `__inline_or_static`, which for all other
compilers is set to `inline`. For pre-C99 compilers it is set in the
application visible header to `static`. For the compilation of musl
itself it is set to empty, such that the symbol is produced and
available in musl.

So under all circumstances the symbol will be available as external
symbol in musl.

Applications that link against such a compiled library and that don't
have inline, a compilation will produce a `static` symbol in each
TU. This is not completely conforming, but we cannot expect much more
for pre-C99 compilers.

On the other hand if the application is compiled with existing
`inline`, this does whatever the compiler thinks is best. If it then
needs an external symbol in the C library, that symbol is available
under all versions.
---
 include/features.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/features.h b/include/features.h
index f200a6b4..5d460800 100644
--- a/include/features.h
+++ b/include/features.h
@@ -24,9 +24,13 @@
 
 #if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
 #define __inline inline
-#elif !defined(__GNUC__)
+#define __inline_or_static inline
+#else
+#if !defined(__GNUC__)
 #define __inline
 #endif
+#define __inline_or_static static
+#endif
 
 #if __STDC_VERSION__ >= 201112L
 #elif defined(__GNUC__)
-- 
2.34.1

[musl] [C23 feature tests 4/6] Add a feature test for the _BitInt types.

[Jens Gustedt]

This test is not needed for the configuration of musl itself, but only
for the interfaces that are offered through headers.
---
 include/features.h | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/features.h b/include/features.h
index 4083436d..f200a6b4 100644
--- a/include/features.h
+++ b/include/features.h
@@ -61,10 +61,14 @@
 #define __has_VA_OPT1(...) __has_VA_OPT2(__VA_OPT__(,) 1, 0,)
 #define __has_VA_OPT __has_VA_OPT1(C23)
 
-// If the platform supports the 128 integer type and has _BitInt(N)
-// support where N large enough (all C23 compiler should have the
-// latter)
-#if __SIZEOF_INT128__ && (__BITINT_MAXWIDTH__ >= 128)
+// If the platform supports the _BitInt(128) types (all C23 compiler
+// should have that)
+#if __BITINT_MAXWIDTH__ >= 128 || BITINT_MAXWIDTH >= 128
+#define __has_bitint128 1
+#endif
+
+// If the platform supports the 128 integer type and has _BitInt(128)
+#if __SIZEOF_INT128__ && __has_bitint128
 #define __has_int128_t 1
 #endif
 
-- 
2.34.1

[musl] [C23 feature tests 0/6] tests needed for C23 interfaces

[Jens Gustedt]

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

Re: [musl] [C23 feature tests 0/6] tests needed for C23 interfaces

[Rich Felker]

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

Re: [musl] [C23 feature tests 0/6] tests needed for C23 interfaces

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

Rich,

on Wed, 24 May 2023 09:58:37 -0400 you (Rich Felker <dalias@libc.org>)
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.
> > 
> > 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.

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ₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]