From: bc@freeuk.com   
      
   On 01/12/2025 18:33, David Brown wrote:   
   > On 01/12/2025 18:19, bart wrote:   
      
   > If you are implementing only a partial sort-of-C compiler, with a view   
   > to acting as a limited tool for a specific close subset of C, then it's   
   > fine to change or skip rules.  Perhaps your tool is never called upon to   
   > do arithmetic on types that are not of size "int" or above, or perhaps   
   > you actively decide to have different rules.  That's okay - but it would   
   > be misleading to call it a "C compiler".   
      
   I call it a C-subset compiler, for a standard somewhere between C90 and   
   C99. It's a C subset that my transpiler projects used to generate.   
      
   It seems to cover enough of the language to compile projects like   
   sqlite3, Lua, Tcc, Clox, stb_image, LibJPEG, and for any programs /I/   
   might write.   
      
      
   >>   
   >>> but it still does so more than an untyped language like assembly.   
   >>   
   >> There is type-specific stuff going on, but it's done via the choices   
   >> of instruction.   
   >   
   > We are talking about C, here in a C newsgroup.   
      
   Sure; that's why you mentioned assembly.   
      
   > The thing you have to remember about implementations, is that nobody   
   > really cares how hard it is to implement a particular C feature.  The C   
   > standards folk care that it is /possible/ to implement it, not if it   
   > happens to be easy or difficult for any particular compiler (especially   
   > an obscure private sort-of-C compiler that is only used by one person).   
      
   > They do provide some escape hatches for implementers who feel a   
   > particular feature is too difficult to make for the amount of use it   
   > would get from their users - a number of C features are optional, and   
   > for _BitInt, you can limit the size to just 64 bits.   
      
   So they do care.   
      
      
   >> This is related to my remark about LLVM and its building-in of such   
   >> types. But LLVM is some 3-4 magnitudes bigger in scale than what I do,   
   >> and famously slow and cumbersome in operation.   
   >>   
   >   
   > The _BitInt feature is not designed arount LLVM.  You are mistaken in   
   > believing so.  It took inspiration from clang's _ExtInt feature and how   
   > it could be used, not how it was implemented.   
      
   See this article about ExtInt:   
      
   https://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html   
      
   These are quotes:   
      
   "I finally committed a patch to implement the extended-integer type   
   class, _ExtInt after nearly two and a half years of design and   
   implementation."   
      
   "provides a language interface for LLVM's extremely powerful integer   
   type class."   
      
   (From the N2472 link in the article:)   
   "The LLVM compiler provides support for iN types in the intermediate   
   representation, so it is straightforward to implement in this compiler"   
      
   So the existence of LLVM's bigint types appear to be a significant   
   factor which led to ExtInt and then to BitInt.   
      
   (But it's not clear what that 2 1/2 years was spent doing, unless it is   
   what they mean by 'straightforward'.)   
      
      
   > But if you want to have types like that in C, they are called "uint8_t",   
   > etc.  You know this.  You only use these silly abbreviations for   
   > provocation,   
      
   No, because everyone knows what they mean, across languages too.   
      
     so that you can yet again blather on about how some other   
   > irrelevant language uses them and somehow feel smug about it all.   
      
   You're damn right about feeling smug about being able to write:   
      
       proc F(u64 a, b, c, d)   
      
   where I can instantly see that this takes 4 parameters that share the   
   same type, and not:   
      
       void F(uint64_t a, uint64_t b, uint64_t c, uint64_t d)   
      
   or worse (presumably what people had to before C99):   
      
       void F(unsigned long long int a, unsigned long long int b, unsigned   
   long long int c, unsigned long long int d)   
      
      
   > They exist in the C standard regardless of any headers, because the C   
   > standard - the definition of the C language - is independent of any   
   > program.   
      
   Sure, that's why I can write code like this, without stdint.h:   
      
       int32_t abc;     // "error: unknown type name 'int32_t'"   
      
   Or with stdint.h:   
      
       int int32_t;     // within a block scope   
       int64_t int64_t;   
       typedef uint8_t int16_t;   
      
   So it IS dependent on a particular program. At least I have to hand it   
   to C to be able to write such nonsense.   
      
   >>   
   >> Fortunately I'm 100% certain that no one reading this is scratching   
   >> their heads about what those types could possible mean.   
   >>   
   >>>   And I expect most C programmers figure things out using the very   
   >>> simple and consistent rules of the language.   
   >>   
   >> The chart demonstratates a number of inconsistencies.   
   >>   
   >   
   > No, it does not - at least, not inconsistencies in C.  It may   
   > demonstrate inconsistencies in your understanding and misunderstanding   
   > of the language.   
      
   The inconsistencies are to do with the irregular pattern of those S and   
   u letters.   
      
   > No.  As I said, the rules are clear and simple.  Anyone so incapable of   
   > learning that they have trouble with them, is likely to have a great   
   > deal of difficulty doing much programming.   
      
   There are two approaches to creating a product like an application, or a   
   programming language (or lots of things actually). This is the bad way:   
      
   * Not caring about how complicated, badly designed and inconsistent it   
   is, and telling people to RTFM if they complain, or simply being   
   insulting about the abilities   
      
   Remember that people have their own work to do and your product is just   
   a tool.   
      
   > (And again, I point out that I do not think the C rules here are the   
   > best options for a programming language.  But that is my personal   
   > opinion, and it does not affect my ability to understand the rules and   
   > write correct C code using them.)   
      
   Maybe you should have been more vocal about it. /You're/ the one who's   
   using it every day. I'm more of an observer.   
      
   >> (My language also has rules, but the equivalent chart is simpler:   
   >> every entry has 'S' except for u64/u64 (and I'm working on that!).   
   >>   
   >   
   > That would be an alternative set of rules that would also be easy to   
   > learn.  And it would be, IMHO, at least as bad as C's choices.  There is   
   > no set of rules that can handle mixed signed arithmetic well and   
   > implicitly without expanding type sizes.  Your language is different   
   > from C's, not better.   
      
   I make the i64 type dominant. i64 can completely represent the values of   
   all other smaller integer types, signed and unsigned, except for u64.   
      
   Some i64/u64 combinations are disallowed (because they can give   
   unintuitive results).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)