4 ms·

Why are these defined as macros at all? A function call would come with overhead, of course, but wouldn't compilers be able to inline that anyways?

lifthrasiir 2y ago
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.
- kevin_thibedeau 2y ago
  C11 does with _Generic but it is limited in ways that make min/max implementations flaky.
  - pyth0 2y ago
    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.
    - dwattttt 2y ago
      Generic dispatching all the type combinations (or warning or erroring) wouldn't be a problem in a project the scale of the Linux kernel. I'm unfamiliar with the incantations needed to try preserve constant expressions though, that might be too much for them.
      - lifthrasiir 2y ago
        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))
  - kelnos 2y ago
    Also _Generic is intended for a function that takes a single varying type. The kernel's min/max macros allow you to safely mix types.
ufo 2y ago
Another issue is that some of these macros are intended to be used in a constant context, such as array dimensions.
- LeifCarrotson 2y ago
  *constant
olliej 2y ago
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.

lifthrasiir 2y ago

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.

kevin_thibedeau 2y ago
C11 does with _Generic but it is limited in ways that make min/max implementations flaky.
- pyth0 2y ago
  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.
  - dwattttt 2y ago
    Generic dispatching all the type combinations (or warning or erroring) wouldn't be a problem in a project the scale of the Linux kernel. I'm unfamiliar with the incantations needed to try preserve constant expressions though, that might be too much for them.
    - lifthrasiir 2y ago
      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))
- kelnos 2y ago
  Also _Generic is intended for a function that takes a single varying type. The kernel's min/max macros allow you to safely mix types.

ufo 2y ago

Another issue is that some of these macros are intended to be used in a constant context, such as array dimensions.

LeifCarrotson 2y ago
*constant

olliej 2y ago

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.