Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: _BitInt(N) Date: Mon, 01 Dec 2025 15:01:51 -0800 Organization: None to speak of Lines: 87 Message-ID: <87wm353ixs.fsf@example.invalid> References: <10dajlh$ko3c$1@dont-email.me> <10g1qq9$2f8lb$4@dont-email.me> <10g28gm$2mf9s$1@dont-email.me> <10g2f2d$2oufq$1@dont-email.me> <10g2m3v$2s5sa$1@dont-email.me> <10gfkqd$19n2d$1@paganini.bofh.team> <10gftqi$3qhkg$1@dont-email.me> <87sedw9wjh.fsf@example.invalid> <10gga8k$3v646$1@dont-email.me> <10gghbg$3htol$4@dont-email.me> <10gheka$bgvr$1@dont-email.me> <10ghu7d$3htol$5@dont-email.me> <10gi0ep$i4fi$1@dont-email.me> <10gima4$1k84u$2@paganini.bofh.team> <10giq57$rn96$1@dont-email.me> <10gj4g5$1q8vh$1@paganini.bofh.team> <10gk9e7$1cggk$2@dont-email.me> <87tsya7xhe.fsf@example.invalid> <10gl38c$1o9hb$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 01 Dec 2025 23:01:52 +0000 (UTC) Injection-Info: dont-email.me; posting-host="8213f2dfee378269bbe79a5548f849a1"; logging-data="1872136"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yDeFL7kp/pQkhPQQPCzCV" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:VpaKD8dFVBTSAjLPyIpUIdWerh4= sha1:CXbRJAxHFAPoTuGNSD7iXV4q9tk= Xref: csiph.com comp.lang.c:395646 bart writes: > On 01/12/2025 20:34, Keith Thompson wrote: [...] >> I'm not going to take the time to confirm that your chart is >> correct. >> >> It assumes that int is 32 bits; an implementation with 16-bit or >> 64-bit int would require a different chart. >> >> But the fact that you were able to generate the chart means that >> *you already understand the rules*. You just choose to express >> those rules in a way that's more confusing. > > That doesn't follow; the chart was created by a C program (by > submitting 64 combinations of typed variables (eg. issigned(x * y)) to > the macro below, compiled with gcc. OK, apparently I overestimated your knowledge of C's rules (unless you could have reproduced the chart manually). > My own C compiler produces a quite different chart, but I'm not > interested at this point in rewriting the front-end, considering the > many other ways it doesn't conform. > > Fortunately this doesn't seem to affect too many things. > > As example, the above says that i8 * u32 (or u32 * i8) is unsigned; my > chart says it's signed. The difference can be demonstrated here: > > signed char a = -2; > unsigned int b = 13; > > printf("%f\n", (double)(a*b)); > > The output is: > > gcc 4294967270.000000 > bcc -26.000000 > > I don't know about you, but to me, my result looks a lot more > intuitive! So I also didn't /want/ to change it to something I didn't > agree with. Sure, if I didn't know C's rules, your result might seem more intuitive. Nevertheless, it's wrong. C's rules for the integer promotions and the usual arithmetic conversions are clear and unambiguous. If I want to multiply a by b using conversions other than the default ones, I can easily do so with casts: `(int)a * (int)b` for example. Or I can make a and b have more appropriate types in the first place. To be blunt, *I don't care* about the behavior of your personal non-conforming C compiler. You're absolutely free to make it behave in any way you like, and to have it conform to the C standard or not. But in this newsgroup, I prefer to discuss the actual C language (and occasionally possible improvements that won't break existing code). > ------------------------------------------------- > > #define issigned(x) _Generic((x),\ > int8_t: "S",\ > int16_t: "S",\ > int32_t: "S",\ > int64_t: "S",\ > uint8_t: "u",\ > uint16_t: "u",\ > uint32_t: "u",\ > uint64_t: "u",\ > default: "other") That will yield "other" for plain char, and for some other predefined types. For example, on my 64-bit system I get "unknown" for long long and unsigned long long; with "gcc -m32", I get "unknown" for long and unsigned long. If you want to cover all the predefined integer types this way, I suggest using char, signed char, unsigned char, et al, up to [unsigned] long long. Please note clearly that I am describing how the language is defined, not defending or advocating anything other than knowing how to use it effectively. We already know how much you hate C's type system. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */