https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #17 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Kang-Che Sung from comment #16) > (In reply to Alejandro Colomar from comment #13) > > Not really unimportant. Every time someone writes one of these in a > > project, you need to make sure it's correct, and reviewing it isn't easy. > > And if it has small differences with another version of it, I need to review > > those very carefully. > > This argument doesn't address my concern either. Because how can you be sure > that the compiler and/or C library implement your requested macro correctly? > Ultimately you just move the problem, not solve it. > > Of course you may trust the compiler more than whatever implementation you > come up, yet ultimately there is gotta be *someone* who reviews it. And no > human person is less error prone than others. There are less compilers than programs that use it, so there will be less points of failure if this is implemented in the compiler instead of in each program that uses it. > > > > > > > Unfortunately this doesn't convince me. > > > > > > I know your position - you want this to be available as a compiler > > > builtin, > > > and I support that. However, there are many code out there that aim for > > > older versions of the standard, thus pushing this into C2x would not, > > > AFAICT, solve the concerns of other programmers when the macro code needs > > > a > > > fallback (for pre-C2x compilers). > > > > 20 years from now, when all compilers support _Minof/_Maxof, people will be > > happy that we did this. Otherwise, they'll keep writing their own stuff. > > > > The same could've been said of _Bool back then, and we can now use it to > > make our booleans simpler and safer. Or with many other features. Some > > programs will be able to use them sooner, others later. > > I knew the reason why the C language didn't have boolean types when it was > conceived, and even with the `_Bool` type in C99 (and now `bool` in C23), The type is still _Bool in C23. bool is a predefined macro. > there are caveats. Such as: (a.) Direct casting to `(bool)` is unportable. Casts in general are dangerous, and my ideal amount of them is 0. For booleanizing a value, I prefer '!!'. > (b.) Making an array of booleans (`bool []`) can get neither performance or > memory size saving for you, so avoid this use of booleans unless you know > what you're doing. But _Bool is useful, and we're now better with it. Yeah, don't use it in arrays unless you know what you're doing. > > With my macro definition of MAXOF(), you get 6 expansions of the argument. > > When you nest many levels of macros, you certainly want to reduce that, or > > it soon grows exponentially. This would help that. > > Why not just fix your macro definitions? Your MINOF has 5, which is only marginally better than my MAXOF. When nesting macros, you can't fix that too much. The exponential expansion of arguments happens. > I'm taking TCC (Tiny C Compiler) into consideration. There are compilers > that are designed to be small and intentionally cut off features. And as C > language being so essential for many system programs, there would be a > demand for a bootstrappable compiler for a language so essential like this. > So it may be just me, but I don't like when standards mandate unnecessary > features. They are allowed to implement this as a macro. There's no need to implement it as a magic builtin. Just predefined macros #define _Maxof ... #define _Minof ... would work. Like bool is a predefined macro that expands to _Bool. Anyway, it would be interesting to get feedback from a TCC maintainer. I'll write an email to them pointing to this issue.
