OSDev.org

If you must have an integer of size 32 bits, how would you code it up?

int32_t.

If I wanted an unsigned integer of 32 bits, uint32_t .

EDIT: I use these mainly because I'm following the standard.

uint32_t, because then I don't have to "code it up" but merely include <stdint.h>.

Actually, I have this thing about using a simple 'unsigned' and nothing else. I mainly use a type:

uarch_t (Unsigned Architecture type) that is nothing more than a typedef unsigned uarch_t.

This means that on a compiler that's 64 bit, I assume it would take a simple unsigned to be a 64 bit integer type. for a specific 'long' I use 'ulong32'.
I use the uarch_t almost throughout my source, assuming it will help with portability later. If not, then it doesn't hurt, either. The 's/uqword64' is an artifact from my earlier days when I was still getting into the full swing of OSDev.

I both use uint32_t (because of stdint.h) or UINT and DWORD types depending on what I am working with.

@gravaera: I hope you know that "unsigned" is the same exact thing as "unsigned int".

In my kernel I use "byte", "word", and "dword" for the types that must be 8/16/32 bits. But I admit that it's a pretty crappy way to do things.

rofl I just realized. No one voted u32int. Yet we have a huge piece of tutorial code in the wiki using nothing but u32int.. or wait, maybe that was what JamesM used.. I can't remember lol, but yea I forgot about the DWORD and such types that I myself once used..

I use uint32... because that way I don't have to put so many _t's

@manonthemoon: yea. I just have certain weird paranoia and practices I adhere to while coding that I never drop... Even if technically they don't hold that much water.

I like u32int because the numbers separate the characters... it's more aesthetically pleasing

xvedejas wrote:I like u32int because the numbers separate the characters... it's more aesthetically pleasing

I prefer to say 40$ so that it reads "forty dollars" but it goes against all standards, so everyone would laugh at me for using such a thing... lol

earlz wrote:

xvedejas wrote:I like u32int because the numbers separate the characters... it's more aesthetically pleasing

I prefer to say 40$ so that it reads "forty dollars" but it goes against all standards, so everyone would laugh at me for using such a thing... lol

So I guess you're a 0000h guy, not a 0x0000 guy when it comes to writing hexadecimal? What if you want to write in octal?

MessiahAndrw wrote:

earlz wrote:

xvedejas wrote:I like u32int because the numbers separate the characters... it's more aesthetically pleasing

I prefer to say 40$ so that it reads "forty dollars" but it goes against all standards, so everyone would laugh at me for using such a thing... lol

So I guess you're a 0000h guy, not a 0x0000 guy when it comes to writing hexadecimal? What if you want to write in octal?

you missed the point. People should follow such common and in-place standards(which are as easy to follow as these) no matter what their silly personal preference is..

(as in, I forgot the <sarcasm> tag)

Personally I use Uint32 (but when working on 32-bit systems, Uint means the same)

I almost always use my own "types.h" which just creates u8, s8, u16, s16, etc.
I know the types are integers, so I don't need "int" or "long" or some other word in the type.
This way there's no space in the type, it's usually less than 4 characters long, and I see the signedness
and length at once (which is all I need).

Now that doesn't mean I would ever typedef float or double to something different (unless you want
f32, f80, f128, ... f60? which I don't find necessary).