From: Keith.S.Thompson+u@gmail.com   
      
   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 */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)