sizeof int and long
- AlfaOmega08
- Member
- Posts: 226
- Joined: Wed Nov 07, 2007 12:15 pm
- Location: Italy
sizeof int and long
Some books says that sizeof(int) = 2, and sizeof(long) = 4.
I've always known that sizeof(int) = sizeof(long) = 4...
Also gcc agree with my opinion...
So, what's the TRUE size of an int?
I've always known that sizeof(int) = sizeof(long) = 4...
Also gcc agree with my opinion...
So, what's the TRUE size of an int?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
short answer: undefined
long answer: http://www.nirvani.net.nyud.net:8090/docs/ansi_c.pdf
long answer: http://www.nirvani.net.nyud.net:8090/docs/ansi_c.pdf
- AlfaOmega08
- Member
- Posts: 226
- Joined: Wed Nov 07, 2007 12:15 pm
- Location: Italy
please typedef one of the standard types: (u)int8/16/32/64_t, don't use yet another name (and even one that is not really defined in terms of size).
typedef unsigned long uint32_t;
will work on a 32bit x86 gcc. It won't however for 64bit x86 gcc (unsigned long will be 64bit there, unsigned int however is 32bit there).
typedef unsigned long uint32_t;
will work on a 32bit x86 gcc. It won't however for 64bit x86 gcc (unsigned long will be 64bit there, unsigned int however is 32bit there).
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
stdint.h helps make clearer and more portable code... and as bluecode said, long is a 64-bit type on AMD64, but it's 32-bit on x86 systems, int can even be a 16-bit type on some architectures.
Quite a few people have been making their own types for this purpose, but it's probably better to use the "standards".
http://www.opengroup.org/onlinepubs/009 ... int.h.html
Right, so a partial stdint.h could look like this:
That way, when you decide to port to an additional architecture.. you can make changes accordingly.
Quite a few people have been making their own types for this purpose, but it's probably better to use the "standards".
http://www.opengroup.org/onlinepubs/009 ... int.h.html
Right, so a partial stdint.h could look like this:
Code: Select all
#if defined(__i386__) || defined(__amd64__)
typedef char int8_t;
typedef unsigned char uint8_t;
typedef short int16_t;
typedef unsigned short uint16_t;
#if defined(__i386__)
typedef long int32_t;
typedef unsigned long uint32_t;
#elif defined(__amd64__)
typedef int int32_t;
typedef unsigned int uint32_t;
#endif
typedef long long int64_t;
typedef unsigned long long uint64_t;
#endif
and make sure you've got some assert(sizeof(uint32_t) == 4) and alike somewhere...
Before I forget, the following will work at least on x86 and x64, AFAIK. Not standard, but working without those __X__ macros...[/code]
Before I forget, the following will work at least on x86 and x64, AFAIK. Not standard, but working without those __X__ macros...
Code: Select all
typedef unsigned char uint8;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long int uint64_t;
21 is only half the truth...
Code: Select all
Before I forget, the following will work at least on x86 and x64, AFAIK. Not standard, but working without those __X__ macros...
Do not assume.
The compilers do you a courtesy and export intX_t and uintX_t in <stdint.h>. Use those. Don't try to come up with your own clever typedefs. They will break. Sooner or later.
Every good solution is obvious once you've found it.
Yeah, I was going to try that but sadly, I couldn't figure out how to get GCC to include the standard freestanding headers!The compilers do you a courtesy and export intX_t and uintX_t in <stdint.h>. Use those. Don't try to come up with your own clever typedefs. They will break. Sooner or later.
Maybe that's because I'm using the cross-compiler from the tutorial (without-headers)?
But what'll happen when I do compile it with newlib headers - there's actually no actual code involved in the freestanding headers other than typedefs/macros, right?
"Sufficiently advanced stupidity is indistinguishable from malice."
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
I've found the include directory for the cross-compiler build in $PREFIX/lib/gcc/$TARGET/<version>/include, but mine doesn't have a stdint.h (it has things like syslimits.h, stddef.h, among other files).
On the other hand, if you do a newlib port you get a stock stdint.h that newlib provides that works with minor changes out of the box.
On the other hand, if you do a newlib port you get a stock stdint.h that newlib provides that works with minor changes out of the box.
The gcc crosscompiler does not come with a stdint.h. At least none of my four gcc crosscompiler does come with one.But it does come with: float.h iso646.h limits.h stdarg.h stdbool.h stddef.hSolar wrote:No, don't copy from your system include directory. GCC should have built a stdint.h during the cross-compiler setup; I can't check ATM where it's located exactly, but use that, not your system's one (configs may differ).
Ah well... the safe bet, then, would be to construct your own stdint.h using the values found in limits.h.
I will have to have a closer look at this once things get back to normal. (Our household is still mostly packed up in boxes after relocation.)
I will have to have a closer look at this once things get back to normal. (Our household is still mostly packed up in boxes after relocation.)
Every good solution is obvious once you've found it.