<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.
Alex
I'd like to register my vote of disapproval of a move to stdint.
u8/u16/u32 are a perfectly fine set of types and the Linux kernel uses them a lot. We owe our usage of these short type names to our Linux kernel heritage. Besides that, they are very convenient to type und read due to their short names. I stopped counting how often I typed u_int32t instead of uint32_t. We're not userspace, so we have to provide our own stdint.h anyway.
Let's just standardize on the short type names.
Regards, Carl-Daniel
Standardizing on the short names is easy. Converting to them is even easier, via spatch. I'll +2 such patches :-)
We can make the cut in less time than it takes to discuss it :-)
I'm not that concerned either way, except that, historically, coreboot has gone with the short names.
ron
On Tue, Jan 28, 2014 at 2:44 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I'd like to register my vote of disapproval of a move to stdint.
u8/u16/u32 are a perfectly fine set of types and the Linux kernel uses them a lot. We owe our usage of these short type names to our Linux kernel heritage. Besides that, they are very convenient to type und read due to their short names. I stopped counting how often I typed u_int32t instead of uint32_t. We're not userspace, so we have to provide our own stdint.h anyway.
Let's just standardize on the short type names.
Regards, Carl-Daniel
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, 2014-01-28 at 23:44 +0100, Carl-Daniel Hailfinger wrote:
I'd like to register my vote of disapproval of a move to stdint.
u8/u16/u32 are a perfectly fine set of types and the Linux kernel uses them a lot.
It shouldn't. They're equally anachronistic there. The Linux kernel stopped building with C89 a *long* time ago.
We owe our usage of these short type names to our Linux kernel heritage. Besides that, they are very convenient to type und read due to their short names. I stopped counting how often I typed u_int32t instead of uint32_t.
Ah yes, that was the BSD abomination I'd forgotten. Wasn't it u_int32_t or something like that?
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.
On Tue, Jan 28, 2014 at 1:11 PM, mrnuke mr.nuke.me@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
On Tue, 2014-01-28 at 13:11 -0600, mrnuke wrote:
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.
Right. The short ones are a hangover from before C99 added the real, standard types.
We really don't want to be screwing around with non-standard nonsense like DWORD, u32, and whatever the BSDs use which ISTR is different again.
Just join us in the 21st century and use the C standard types. Yes, they're different to what you were used to in the last millennium. You'll get over it.
2014-01-29 David Woodhouse dwmw2@infradead.org:
On Tue, 2014-01-28 at 13:11 -0600, mrnuke wrote:
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.
Right. The short ones are a hangover from before C99 added the real, standard types.
We really don't want to be screwing around with non-standard nonsense like DWORD, u32, and whatever the BSDs use which ISTR is different again.
Just join us in the 21st century and use the C standard types. Yes, they're different to what you were used to in the last millennium. You'll get over it.
I have the same opinion - use the types C99 provides.
greets -- Christian Gmeiner, MSc
On Wed, Jan 29, 2014 at 5:05 AM, David Woodhouse dwmw2@infradead.org wrote:
Just join us in the 21st century and use the C standard types. Yes, they're different to what you were used to in the last millennium. You'll get over it.
like gint :-)
Anyway, I'm not that worried about it. Typedef was created for a reason: so people could define types convenient to their project. I figure you all can work it out.
:-)
ron
-
Aaron Durbin -
Carl-Daniel Hailfinger -
Christian Gmeiner -
David Woodhouse -
mrnuke -
ron minnich