Some pieces of code in the article look suspicious:

    #define LUAI_IS32INT ((UINT_MAX >> 30) >= 3)

If unsigned int is just 16 bits wide, then `65535 >> 30` shifts by more positions than the width of the type, which should be undefined behavior, right?

    #define NB CHAR_BIT
    #define MC ((1 << NB) - 1)

If we have a DSP machine (as mentioned in the article) where CHAR_BIT is 16 and int is 16 bits, then `1 << NB` is `1 << 16` which shifts as much as the width of the type, which I believe is undefined behavior as well.

Regardless of whether you think C's flexible integer sizes are good or bad, and whether it helped propagate the language, there's no denying that if you want to write portable code across machines, you have to put in more effort compared to a language with fixed-size integers. Whether this matters or not is a matter of situation and opinion.

Other than that, I made a simulator where you can set the bit width of each integer type, and then it shows you how `x operation y` gets promoted to some output integer type. https://www.nayuki.io/page/summary-of-c-cpp-integer-rules section "Conversion rules simulator"