Aaron Durbin wrote:
We should accept patches that come in any form.
I could not disagree more with this in general.
I disagree less strongly for the specific case of u32 vs. uint32_t but I do still disagree - I also like the stdint types, mostly because they are becoming widely available.
I think they look ugly, but I also have a strong preferece to always keep declarations at start of functions rather than as close to the use as possible, so they don't have to be all over the code.
I also might add that the kernel allows such types:
It's allowed to be better than the kernel.
I don't think that adds any barrier to readability.
I think it does. Not a very large barrier, but it does add one.
It's nice to have a code style to fall back on, maybe even neccessary, when all developers don't prefer the same style anyway, which is, well, unusual.
//Peter
A lot of great opinions from both sides. I have created a small entry into our coding guidelines describing this debate [1].
I've prepared a small summary of the three coding styles we are using with respect to this issue:
Older than grandma grandma current ------------------ ------- ------- unsigned long long u64 uint64_t long long ??? int64_t unsigned long u32 uint32_t long ??? int32_t
I have seen zero lobbying for "Older than grandma", which is good. The debate remains between "grandma" and "current".
The main issue here is consistency. Having both styles is bound to clash sometime in the future. We have code that calls "current" functions and stores the result into "grandma" variables. I doubt carrying on both styles is a good idea in the long term.
I feel awkward lobbying for "current" considering I almost had a aneurysm when I first stumbled on usage stdint types in coreboot. Since then, I've started doing minor refactoring on our userspace tools, and lo and behold, we have duplicate files for userspace and coreboot. One example is the lzma decompressor, whose userspace counterpart I am currently refactoring.
Userspace is stdint, no debate about it. So what happens when I take the refactored decompressor, and put it in coreboot proper? For consistency's sake, I would have to change "current" types to "grandma" types, which is, in plain english, an imperial pain in the poop hole. This is the exact argument Aaron and Peter are making, and it is the only practical argument I have seen thusfar.
We're not linux, so the linux-legacy argument fails right off the bat, in my view.
The other practical argument is finger strain from typing the "_t". I used to be a strong believer in that, until a bunch of other projects told me to "suck it up". Seriously, use a good editor, and it will autocomplete the "_t" for you. You'll soon find that looking at code for hours at a time is a lot more comfortable, and less eye-straining. "u32" is just too short to be eye-friendly.
I'd like end by quoting my favorite part of this discussion:
Seriously though, you'll *get over that* really quickly if you start using C99 standard types as a matter of routine. Your fingers don't take that long to learn, as a one-off.
But yes, you highlight the issue which is caused by people clinging to their own *nonsense*, *non-standard* types instead of using the language properly. Your fingers have to be retrained every time you switch between projects.
(empasis added)
Alex
[1] http://www.coreboot.org/Development_Guidelines#Variable_types
-
mrnuke -
Peter Stuge