On 2026-05-10 22:47, Bruno Haible wrote:
Paul Eggert wrote:
+# define _GL_TYPE_SIGNED(t) \
+ (_Generic ((t) {0}, \
+ bool: 0, char: CHAR_MIN < 0, signed char: 1, unsigned char: 0, \
+ short int: 1, unsigned short int: 0, int: 1, unsigned int: 0, \
+ long int: 1, unsigned long int: 0, long long int: 1, unsigned
long long int: 0, \
+ float: 1, double: 1, long double: 1))
1) What about implementation-defined integer types, such as __int128 [1]?
The compiler will diagnose the error, compilation should fail, and at
that point we can fix things as needed, which should be pretty
straightforward.
I hope that the GCC bug gets fixed before that happens, though; then we
can simply supply a default: case that will work fine, without diagnostics.
2) I've come to dislike _Generic, because it does not work in C++ mode
(except in clang++):
Yes, _Generic is a pain in general. Here it's not as bad though, because
it need not be used in C++.
#if (defined __GNUC__ && __GNUC__ + (__GNUC_MINOR__ >= 9) > 4 && !defined
__cplusplus) /* C mode */ \
|| (defined __clang__ && __clang_major__ >= 3) /* both C and C++ mode */ \
|| (defined __SUNPRO_C && __SUNPRO_C >= 0x5150) /* C mode */ \
|| (__STDC_VERSION__ >= 201112L && !defined __GNUC__) /* C mode */
# define HAVE__GENERIC 1
#endif
Yes, it does seem that nearly every file that tests whether _Generic
works uses a different heuristic to check. At least intprops.h has an
excuse for being different, as these _Generics are to improve the
quality of diagnostics, not for correctness, so it's OK if the test for
simplicity's sake excludes some platforms.
