https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #15 from Kang-Che Sung <Explorer09 at gmail dot com> --- (In reply to Alejandro Colomar from comment #13) > > > > Unimportant differences, I would say. > > 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. I have a personal experience with an implementation of strtol(3) that has a non-compliant behaviour on one edge case, I remember it's from MSVC / Windows SDK and yet I can't remember which version of it has the error or whether they have fixed it now. My point is, things can go wrong when they go wrong. > > > > 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), there are caveats. Such as: (a.) Direct casting to `(bool)` is unportable. (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. > > 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? I don't see this as a compelling reason. (Unlike `offsetof` and `_Containerof` macros, which would involve in undefined behavior (null pointer dereference) with their usual implementations, which make them worth implementing as compiler built-ins, `MAXOF()` can be implemented without undefined behavior, which makes a built-in for it technically unnecessary (yet encouraged).) > > > > > I would say making `_Maxof` a compiler built-in does not require the keyword > > to be standardized, and sometime it would be better for this built-in to be > > left as an extension, not mandatory for an implementation. > > I would be happy with it being an extension, but I think no compiler will be > against standardizing it, at which point it's easier to just standardize it. 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.
