C doesn't have any type-generic function declaration. So any viable solution had to be at least partially powered by a macro and resulting (one-directional) type inference.
Even with _Generic you can't declare generic functions. You'd still need a macro call that uses _Generic to dispatch different implementations depending on the parameter types.
The concrete problem that the kernel is facing is an exponential growth of macro expansion. Any current solution, safe or not in terms of re-evaluation, needs at least two copies of both arguments to be expanded [1], so expressions like `min(min(a, b), c)` will expand some arguments four times. The growth factor would be much larger than two if the definition wasn't carefully designed to avoid such cases.
[1] `_Generic` also requires at least two because you need one copy to select the generic implementation and another to call it. C23 `typeof` (or the equivalent GNU extension) allows for a compact type tuple matching:
inline static int max_int(int x, int y) { return x > y ? x : y; }
inline static unsigned max_uint(unsigned x, unsigned y) { return x > y ? x : y; }
/* ... */
#define MAX(a, b) (_Generic( \
(void (*)(typeof(a), typeof(b))) NULL, \
void (*)(int, int): max_int, \
void (*)(unsigned, unsigned): max_uint, \
/* ... */ \
default: max_type_error \
) (a, b))
The problem is C lacks an equivalent to C++’s constexpr (or preceding template insanity), so you can’t use functions in constant contexts, eg
struct S {
int foo[max(10, 15)];
}
Isn’t possible in C, macros are the only option.
So even if you were to try to use _Generic in a macro to handle type correct dispatch you would not be able to use that macro in many of the contexts it is needed.
Honestly constexpr is something that would really help C, and does not need to bring in any other c++ features. Although I guess in this case the lack of the full template and such features set would mean matching the kernel requirements would still require a macro+_Generic to adopt.