Hi Florian, On 8/23/22 09:58, Florian Weimer wrote: > * Alejandro Colomar: > >> +.SH EXAMPLES >> +The following program demonstrates how to write >> +a replacement for the standard >> +.BR imaxabs (3) >> +function, which being a function can't really provide what it promises: >> +seamlessly upgrading to the widest available type. >> +.PP >> +.\" SRC BEGIN (_Generic.c) >> +.EX >> +#include <stdint.h> >> +#include <stdio.h> >> +#include <stdlib.h> >> + >> +#define my_imaxabs(j) _Generic((intmax_t) 0, \e >> + int: abs(j), \e >> + long: labs(j), \e >> + long long: llabs(j) \e >> + /* long long long: lllabs(j) */ \e >> +) > > The macro name does not really match what the function does. It's a > type-generic abs function, not related to the max function or intmax_t.No, it's not a type-generic function, per the usual definition of "type-generic function". It doesn't depend on the input type. The selector is fixed. It's actually more or less like switch-case-ing on a compile-time constant. BTW, I could improve it to be INTMAX_C(0).
It behaves the same as the standard imaxabs(3):The input is converted to intmax_t before being passed to the function (i.e., __int128 would be truncated to intmax_t), and the output is of type intmax_t. (Or, actually, the underlying type behind intmax_t.)
> > Note that this approach does not really work that well in practice > because macros using _Generic expand all the alternativesYeah, it expands all, instead of behaving like a lot of #if's. Maybe #if's would be better for a libc, but _Generic() could be good enough for some implementations, or could be good for a user that doesn't want to use the broken-by-design standard imaxabs(3).
> (in current > implementations; doing this differently requires deviating from the > layered implementation strategy suggested in the C standard).The standard is broken in this regard. My hint is to fix the standard, not to fix libc. Although glibc might benefit from deviating from the standard for good here.
The problem is in emitting linker code for a function whose type is expected to change in the future. A macro is free from ABI problems by not emitting any linker code.
BTW, as a very-long term suggestion improvement for libc and ISO C, functions should be emitted only for fixed width integer types, like
abs32(), abs64(), abs128(), ...If only fixed-width function identifiers existed (instead of labs() and llabs(), ...), ABI stability would be less problematic than it is right now.
> This > means that _Generic-using macros can only be nested maybe three or four > levels deep, depending on the number of _Generic alternatives on each > level. For <tgmath.h>, this is really not enough, so a high-quality > implementation of <tgmath.h> using _Generic is not feasible. GCC > provides __builtin_tgmath, which is designed in such a way that when > used in a macro, the macro argument is only expanded once.> > Maybe mention this under BUGS?I'm not sure I understand the bug. The code is expanded, but it's not evaluated, right?
I.e., AFAIK, my_imaxabs(++x) would only do the ++ once, right? Is that what you were suggesting?
Otherwise, please send a patch for BUGS. It might help. > > C++ templates do not suffer from this particular problem. > > Thanks, > Florian > Thanks for the review!! Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
