Reasonable C types sizes assumption

[suslik]

I'm writting my OS for Intel x86-32 processors (actually for 80386). I don't want to play with other processors. So, it is reasonable to do this assumption: char - 8 bits, short - 16 bits, int - 32 bits, long - 32 bits? In 32-bit Windows/Linux all C-compilers (as I know) use these sizes. DOS C-compilers when compiling 32-bit code also use these sizes. In 64-bit Windows/Linux I suppose (I can't check it since I have not 64-bit computer) that I need to mention target arch as i386 and compiler will also use these sizes. Am I right?

P.S: I don't like to use int32_t, uint32_t and others, since I think that they are all needed when your C-program is intended for using on a plenty of different archs. In my OS project I use C as a handy replacement for Intel x86-32 asm and not for making my OS cross-platform. It is my choice.

[xenos]

Even if you target only one architecture, there are certainly lots of compilers for that architecture. If you wish to be independent of the compiler you choose, you should not make any assumptions on the size of types, apart from the C language specification.

The only integer types which have guaranteed fixed sizes are intX_t / uintX_t.

[suslik]

To XenOS: do you know any compiler for Intel x86-32 that uses different sizes? OK, I can imagine one that uses 64-bit long, but "int - 32 bits, short - 16 bit, char - 8 bit" is de-facto standard for Intel x86-32 arch!

[JamesM]

To XenOS: do you know any compiler for Intel x86-32 that uses different sizes? OK, I can imagine one that uses 64-bit long, but "int - 32 bits, short - 16 bit, char - 8 bit" is de-facto standard for Intel x86-32 arch!

There are no compilers I know of that deviate from the sizes you've specified.

That said, I'm a C compiler engineer. So if I find you, I will shoot you in the head.

[bluemoon]

I'm writting my OS for Intel x86-32 processors (actually for 80386). I don't want to play with other processors. So, it is reasonable to do this assumption: char - 8 bits, short - 16 bits, int - 32 bits, long - 32 bits? In 32-bit Windows/Linux all C-compilers (as I know) use these sizes. DOS C-compilers when compiling 32-bit code also use these sizes. In 64-bit Windows/Linux I suppose (I can't check it since I have not 64-bit computer) that I need to mention target arch as i386 and compiler will also use these sizes. Am I right?

No. If that happen to your tool-chain it's just luck.

P.S: I don't like to use int32_t, uint32_t and others, since I think that they are all needed when your C-program is intended for using on a plenty of different archs.

Specification are defined not because you like it. And no, even on the same architecture the tool-chain may behave differently due to optimization and all sort of things. One example is that VC may try to optimize a integer into boolean in some situation and alter the size.

It is my choice.

Yes this is your choice, but I wouldn't call that smart.

[xenos]

To XenOS: do you know any compiler for Intel x86-32 that uses different sizes? OK, I can imagine one that uses 64-bit long, but "int - 32 bits, short - 16 bit, char - 8 bit" is de-facto standard for Intel x86-32 arch!

I can write one that does deviate from these values and it will still be compliant with the C language specification.

[turdus]

There are no compilers I know of that deviate from the sizes you've specified.

That said, I'm a C compiler engineer. So if I find you, I will shoot you in the head.

You are too young I remember the time when int used to be 16 bit in pmode

@suslik: that's no longer true that int represents the native word size, because on x86_64 int is still 32 bit, not 64. Also long should be 64 bit on i386, but some os define it as 32 bit (which is simply silly, as you already have a 32 bit numeric type). The forms uint32_t and uint64_t are unambiguous and definite, compiler independent and easier to write and read.

[Owen]

"Conventionally", int was the "native operation size" and long was "the same size as a pointer" (where this is kind of "the way things were" rather than defined by any actual standard)

So, for IA-32, int = long = 32 bits was logical; while for AMD64 int=32-bit, long=64-bit is logical (because 32-bit operations are both smaller and faster), And for IA-16? int=short=16-bit, long=32-bit made sense (also long is >=32-bit)

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

[Antti]

that's no longer true that int represents the native word size, because on x86_64 int is still 32 bit, not 64

I am just wondering whether this is so straightforward with x86-64 or not. I do not think that x86-64 is so 64-bit than 80386 is 32-bit.

I mean that the 64-bit size appears to be "less" native here because of immediate sizes in opcodes and the need of REX prefix when using 64-bit features. It seems the processor likes to behave like a 32-bit one unless a user deliberately wants it to be 64-bit. Nevertheless, the whole idea of x86-64 is to be an extension to x86.

With that in mind, it would be reasonable to keep 32-bit int. In this case, it is not just for the backward compatibility.

[suslik]

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

- Surely it is good to write code that is conform to ANSI C, but sometimes it is safe to do some assumptions like I did. I just ask the osdev community is my assumption reasonable.

I can write one that does deviate from these values and it will still be compliant with the C language specification.

- This compiler will be original but unpractical.

No. If that happen to your tool-chain it's just luck.

- Sorry, but I don't think so.

even on the same architecture the tool-chain may behave differently due to optimization and all sort of things. One example is that VC may try to optimize a integer into boolean in some situation and alter the size

- Interesting, but vaguely.

Conclusion: While I'm writing my OS I try to make some reasonable assumptions to make its code simplier. Some days ago at this forum I tried to proof that my assumptions about bootloader were reasonable (I think that bootloader code need not detect the CPU is >= 80386, check VGA-mode and print verbose error messages), and I failed to do it.

[Griwes]

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

- Surely it is good to write code that is conform to ANSI C, but sometimes it is safe to do some assumptions like I did. I just ask the osdev community is my assumption reasonable.

It is not; only (u)intX_t are reasonable.

I can write one that does deviate from these values and it will still be compliant with the C language specification.

- This compiler will be original but unpractical.

Bullshit, apps that don't care won't care, and apps that care about exact variable sizes use (u)intX_t.

No. If that happen to your tool-chain it's just luck.

- Sorry, but I don't think so.

C standard, as well as C++ standard, disagree with you.

even on the same architecture the tool-chain may behave differently due to optimization and all sort of things. One example is that VC may try to optimize a integer into boolean in some situation and alter the size

- Interesting, but vaguely.

Surprising optimizations like that can really surprise you and take you hours to debug problem arising from them.

Conclusion: While I'm writing my OS I try to make some reasonable assumptions to make its code simplier. Some days ago at this forum I tried to proof that my assumptions about bootloader were reasonable (I think that bootloader code need not detect the CPU is >= 80386, check VGA-mode and print verbose error messages), and I failed to do it.

"simpler code" = code without assumptions. You need no assumption about size of (u)intX_t - it's always X bits. And, no-one disallows you to disagree with people here; just bear in mind that those people here (and that's definitely not including me) have way greater experience in the field of OS development than you - or I - do.

[bluemoon]

You asked, we commented, you stand your choice, good luck.

[Brendan]

Hi,

So, it is reasonable to do this assumption: char - 8 bits, short - 16 bits, int - 32 bits, long - 32 bits? In 32-bit Windows/Linux all C-compilers (as I know) use these sizes.

It might be reasonable to define a new language that is almost exactly the same a C, except for differences in the restrictions the formal specification gives to integer sizes. You could even claim that some existing C compilers support your new "almost identical to C" language.

However, it would be not be reasonable to claim that this new language is C. It'd be a fraudulent/misleading claim if there are differences (even if the differences are minor).


Cheers,

Brendan

[Love4Boobies]

I'm writting my OS for Intel x86-32 processors (actually for 80386). I don't want to play with other processors. So, it is reasonable to do this assumption: char - 8 bits, short - 16 bits, int - 32 bits, long - 32 bits? In 32-bit Windows/Linux all C-compilers (as I know) use these sizes. DOS C-compilers when compiling 32-bit code also use these sizes. In 64-bit Windows/Linux I suppose (I can't check it since I have not 64-bit computer) that I need to mention target arch as i386 and compiler will also use these sizes. Am I right?

Depends on what your definition of "reasonable" is. Given that it's very easy to avoid making these assumptions, why wouldn't you?

P.S: I don't like to use int32_t, uint32_t and others, since I think that they are all needed when your C-program is intended for using on a plenty of different archs.

lol. What is the logic behind that statement?

The only integer types which have guaranteed fixed sizes are intX_t / uintX_t.

The only scalar types, yes.

To XenOS: do you know any compiler for Intel x86-32 that uses different sizes? OK, I can imagine one that uses 64-bit long, but "int - 32 bits, short - 16 bit, char - 8 bit" is de-facto standard for Intel x86-32 arch!

Why is this relevant? No one will do an exhaustive search on all C x86 ABI's, and no one can predict with certainty whether someone will implement a new, incompatible ABI in the future. One of the points of HLL's is independence of the underlying platforms, for portability---you are basically trying write your code such that it is dependent on your platform for no real reason, thus negating that portability for no real reason. So the way I see it, nothing good can come out of it; however, something bad does come out of it: you either restrict yourself to one particular ABI, or decrease maintainability and risk introducing bugs in the case you later change your mind about sticking to one particular ABI (that includes later deciding to also port to a new architecture).

That said, in there x86-64 world, there are competing C ABI's that define types differently (see x32 vs. SysV AMD64), even if it's not the types you happened to mention.

No. If that happen to your tool-chain it's just luck.

You can't write it off to luck---if makes unnecessary assumptions, it's just bad code.

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

<pedantic>It's <stdint.h>, not stdint.h, because it needn't be implemented as a file; indeed, C is often implemented on platforms where file systems don't exist.</pedantic> (u)int_leastN_t and (u)int_fastN_t define types that have a minimum width of N bits but they are also optional.

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

- Surely it is good to write code that is conform to ANSI C, but sometimes it is safe to do some assumptions like I did. I just ask the osdev community is my assumption reasonable.

Those types do not exist in ANSI C (people generally mean C89 when they say that) because that was the only version of the standard that was defined by an ANSI committee. ANSI later adopted ISO C99 and will likely also adopt C11 in the future.

That said, I postulate that it is never entirely safe to make assumptions. If there's something you cannot afford to cover due to limited resources, then state when you define your requirements. Assumptions is something sloppy programmers fall back to.

I can write one that does deviate from these values and it will still be compliant with the C language specification.

- This compiler will be original but unpractical.

It is only made unpractical by your own assumptions.

It might be reasonable to define a new language that is almost exactly the same a C, except for differences in the restrictions the formal specification gives to integer sizes.

While this is theoretically correct, it's anything but reasonable to define a new language as C with a particular ABI. Not to mention that it would only cause confusion.

[Owen]

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

<pedantic>It's <stdint.h>, not stdint.h, because it needn't be implemented as a file; indeed, C is often implemented on platforms where file systems don't exist.</pedantic> (u)int_leastN_t and (u)int_fastN_t define types that have a minimum width of N bits but they are also optional.

(u)int_fastN_t and (u)int_leastN_t are mandatory. uintN_t is mandatory only if the implementation provides an unsigned type of exactly N bits, and intN_t only if the implementation provides a 2s complement signed type of exactly N bits; while the fastN and leastN types are always required

Just use stdint.h, and note the int_fastX_t types also (since they are on some architectures faster)

- Surely it is good to write code that is conform to ANSI C, but sometimes it is safe to do some assumptions like I did. I just ask the osdev community is my assumption reasonable.

Those types do not exist in ANSI C (people generally mean C89 when they say that) because that was the only version of the standard that was defined by an ANSI committee. ANSI later adopted ISO C99 and will likely also adopt C11 in the future.

ANSI adopted C11 when ISO did. ANSI C *is* C89; the first ISO C standard was C90.