[coreboot] Shortened in types (u32) vs stdint types (uint32_t)

[Aaron Durbin]

On Tue, Jan 28, 2014 at 1:11 PM, mrnuke <mr.nuke.me at gmail.com> wrote:
> <rant>
> 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.
> </rant>
>
> 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.

In case anyone cares as to why I started using them is that I like to
hijack bits of code and compile it for userspace when testing and/or
developing new code. It makes that transition easier. Yes, I
understand some sort of wrapper needs to be created sometimes, but if
the code has include <stdint.h> there isn't much more than providing
the other coreboot-specific structs. Yes, it could be argued one way
or another but for strictly library/common code it's pretty easy to
run on one's desktop.

-Aaron