On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote: > There is always the possibility to have the header co-owned by both > the compiler and C library, limits.h style. > Just > #if __has_include_next(<stdckdint.h>) > # include_next <stdckdint.h> > #endif > perhaps guarded with some macro at the end of the GCC version and > do the same at the start of the glibc version again perhaps with some macro. > And leave the compiler specific part to the compiler (perhaps with some > fallback in the libc version if the compiler specific part is missing) and > have the library related part be provided by the C library?
This seems a reasonable approach. If the structure types do make it into future standard versions, we'd need to work out exactly where the division is between compiler and library header responsibilities (where those pieces involving structure types but not library functions go, for example). For operations using structure types with overflow flag we'd need also to work out to what extent it's appropriate to implement those purely in the header with _Generic versus adding new built-in functions or extending what the existing ones can do. > > > What I'm struggling with is enforcing the weird restrictions > > > C23 imposes on these. > > > > It's not clear all those restrictions need to be enforced - this > > definitely seems like a case of undefined behavior to provide useful > > extension space, where for various of those restrictions there are unique > > sensible semantics to provide if the types in question are supported. > > So why does C2X say > Recommended practice > It is recommended to produce a diagnostic message if type2 or type3 are > not suitable integer types, or if *result is not a modifiable lvalue of > a suitable integer type. > ? > Or is it meant that a suitable integer type doesn't need to be necessarily > one that is listed in the previous paragraph? > Perhaps the checking could be guarded on #ifdef __STRICT_ANSI__, sure... Diagnostics are better than doing something completely random - but making it conditional when there are sensible semantics also makes sense. It seems likely a future standard version will support these operations for bit-precise types, at least. (Bit-precise types are generally tricky for type-generic operations; there's no standard way to select on them with _Generic beyond listing individual types with specific widths, and no standard way to determine the width of the bit-precise type of an argument. So implementing some type-generic operations for such types may need new language extensions, prompting WG14 caution about requiring such support - but this also makes support for such types in standard type-generic macros in headers particularly valuable, precisely because they can't be implemented purely in user code using standard language features.) -- Joseph S. Myers jos...@codesourcery.com
