I don't think that's the right question. The question is, why add something non-standard to the language that's easy enough for anyone who wants it to just add as a macro? To me people not answering THIS question is what leads to fragmented languages.
On Fri, Mar 14, 2025, 07:56 grischka via Tinycc-devel < tinycc-devel@nongnu.org> wrote: > On 12.03.2025 13:00, Alejandro Colomar via Tinycc-devel wrote: > > Hi! > > > > I'm proposing a set of operators for ISO C2y: _Widthof, _Minof, _Maxof. > > Someone wondered if it might be more work for small compilers like TCC, > > for little benefit. So I'd like you to read the GCC bug linked below > > and comment if you want. > > > > In the spirit of "One In, One Out": > > Where is the feature(s) that you would suggest to remove instead? > > -- gr > > > > > Have a lovely day! > > Alex > > > > On Wed, Mar 12, 2025 at 10:28:38AM +0000, Explorer09 at gmail dot com > wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 > >> > >> --- Comment #16 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. > >> > >> -- > >> You are receiving this mail because: > >> You reported the bug. > > > > > > > > _______________________________________________ > > Tinycc-devel mailing list > > Tinycc-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
