> It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. How many of them started before stdint.h existed? AFAIK, it's a somewhat recent addition to the C language, and IIRC, for a long time even after it became part of the C standard, some popular C compilers still didn't have…
inttypes.h was added to C99. A quarter of a century ago.
Many C codebases predate that. And Visual Studio for a long time didn’t support anything newer than C89.
(self-reply) One more thing. > I could use _Bool, but I’d rather stick to a natural word size and stay away from its weird semantics. This is even more subjective, but personally I like _Bool's semantics. They mean that if an expression works in an `if` statement: if (flags & FLAG_ALLOCATED) then you can extract that same expression into a boolean variable: _Bool need_free = flags & FLAG_ALLOCATED; The issue is that…
I always just use !! for this case.
Yes, I do this as well. It looks a little funny if you're not used to it, I suppose.
Thanks for bringing this up. There is no reason for modern languages that have proper constants (not preprocessor macros which happen to sometimes be used for them) to use this tedious style. Constants are so innocent and useful. Why indirectly discourage their use by making their usage an eye-bleed?
Great article. One thing for me is that I think we named our variables wrong. We should be specifying the number of bytes, not bits. I use U1, U2, U4, U8, I1, I2, etc Also S for "slot" aka unsigned pointer sized integer (usize_t) Another big point is formatting code to line-up instead of with an autoformatter. When you are doing something which is almost the same but slightly different it helps readability considerab…
Could you elaborate on the reasoning behind using byte length instead of bit length?
Most of the time when I use fixed-width int types I’m trying to create guarantees for bitwise operators. From my perspective I feel like it therefore makes the most sense to name types on a per-bit level.
I mean, being a bit glib here, but a lot of programming is dealing with someone else's type system. Moreover, for those of us who write C fairly often, the mnemonics here are familiar. Actually, as custom type systems go, this one is pretty elegant. Reminds me of Rust.
Yeah but not for basic types. Also, most code mingles sooner or later with other code. Than this is just ugly.
Rust made the correct choice: things used most often should be assigned the shortest names. This "Huffman encoding" style is what natural languages have evolved toward as well. In 2023, if I were to write C, and didn't have existing guidelines to adhere to, I'd most probably introduce the same typedefs as the author here has done.
For example, it would be illegal to do the following: > #define int long Because you're replacing the int keyword with something else. The standard says: > 17.6.4.3.1 [macro.names] paragraph 2: A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 3, or to the attribute-tokens described in 7.6.
That's C++. But I couldn't find the same restriction in C. In fact it seems that C allows it as long as you don't include any of the standard C header. > 7.1.2 "Standard headers" §5 [...] The program shall not have any macros with names lexically identical to keywords currently defined prior to the inclusion of the header or when any macro defined in the header is expanded.
Searching around gave me this from stackoverflow:
In C standard, it is not allowed.
> C11, § 6.4.1 Keywords
> [...]
> The above tokens (case sensitive) are reserved (in translation phases 7 and 8) for use as keywords, and shall not be used otherwise.
> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…
It's the reason Rust makes us use an exclamation mark with macro calls: beware! magic! here! I like this as a convention, but not necessarily as a grammar rule. Printing values is common enough that it shouldn't require shouting for constant attention, simple code shouldn't trigger sensory overload.
I do think that the default convention of SHOUT_CASE for constants in Rust is too in-your-face given that there's nothing about Rust constants that would particularly require them to stand out. I might have gone with CamelCase given that some things in Rust already straddle the "types are CamelCase, terms are snake_case" delineation (enum variants, even data-less ones, are CamelCase, as well as the implicitly defined constant `Foo` for any unit struct `Foo`).
> typedef float f32; > typedef double f64; Assuming float is 32 bits and double is 64 bits sounds like a foot-gun. OpenCV defines a float16_t [0], CUDA implements half-precision floats [1], micro-controllers implement whatever they want. C++23 introduces fixed width floating-point types [2], but not aware of any way to enforce this in C. What I would suggest it to have a macro to check data is not lost at compile tim…
Hopefully I never need to review code written with these definitions. It's an awful idea to do this. The first section shows why some languages have no 'typedef': introducing another layer of aliases is just not a good idea. It's confusing, it changes the appearance to basically a new language. Just use the standard names, instead of redefining your language, like everyone else. This style is almost as bad as '#defin…
> As a side note, I don't understand the #define for sizeof.
Their `size` type is signed. It's `ptrdiff_t`, not `size_t`.