[coreboot] Shortened in types (u32) vs stdint types (uint32_t)
mr.nuke.me at gmail.com
Tue Jan 28 20:11:48 CET 2014
stdint types are ugly as hell. That "_t" at the end is a pain in the ass to
type, every day of the week. They're too freaking long for a variable type. A
real pain. There is still widespread lack of adoption and FUD towards these
types. I'm willing to bet that, had they been named properly, like uint32 (not
a typo, there is no "_t"), the adoption would not be an issue.
We normally use supershort in types in coreboot (u32). I am, of course,
ignoring the legacy legacy types such as unsigned long, which have sadly
persisted in coreboot source from the very early days. Personally, I'm a fan
of u32 short types, and I really enjoy working with them. However, recent
contributions to other projects have forced me to suck it up and deal with
their stdint evil sisters.
To the real point: We have lots of recent contributions from google, which use
stdint types. They're compatible with our old short types because, well,
they're typedef'd from the same thing. The problem however, is that it creates
more inconsistency within our tree. As a result, I propose we make stdint
types mandatory, and deprecate shortname types. People don't want to learn a
separate set of data types for every project to which they contribute. stdint
types solve this problem by being standardized. I am far from liking this
change, but it just makes sense.
So, can we get votes of approval? I can add this info to the Coding Guidelines
if there is enough support. Hopefully, we'll be able to migrate to stdint
entirely, and drop shorties.
More information about the coreboot