liv2hak liv2hak - 1 year ago 34
C Question

size of basic data types in C

I have a sample program that I copied from some website.

int main(void)
int answer;
short x = 1;
long y = 2;
float u = 3.0;
double v = 4.4;
long double w = 5.54;
char c = 'p';

typedef enum

/* __DATE__, __TIME__, __FILE__, __LINE__ are predefined symbols */
#if 0
printf("Date : %s\n", __DATE__);
printf("Time : %s\n", __TIME__);
printf("File : %s\n", __FILE__);
printf("Line : %d\n", __LINE__);

/* The size of various types */
printf("The size of int %zu\n", sizeof(answer));
printf("The size of short %zu\n", sizeof(x));
printf("The size of long %zu\n", sizeof(y));
printf("The size of float %zu\n", sizeof(u));
printf("The size of double %zu\n", sizeof(v));
printf("The size of long double %zu\n", sizeof(w));
printf("The size of char %zu\n", sizeof(c));
printf("The size of enum %zu\n", sizeof(codes_t));

return 0;

I ran this program and the output that I got is as follows.

The size of int 4
The size of short 2
The size of long 8
The size of float 4
The size of double 8
The size of long double 16
The size of char 1
The size of enum 4

I am running this on a linux PC that is running 64-bit Ubuntu.My question is if I were to run the same program on a 32-bit machine will I see different results.Or in other words does the size of the basic data types depend on

  1. processor

  2. Operating System

  3. anything else

Answer Source

Subject to having to install some libraries [probably just glibc] in it's 32-bit variant, you should be able to try this yourself by using gcc -m32 myprog.c [or clang -m32 myprog.c].

However, the only thing of your items that have been listed that will change if you move from a 64-bit x86 linux system to 32-bit x86 linux system, using gcc-based compilers, is the size of long. Note the heavy qualification of x86, gcc, etc - compilers have a lot of freedom. Someone could write a compiler for Linux that uses 16-bit int and 64-bit long on a 32-bit system with no huge amount of difficulty. Using that compiler to compile the Linux kernel and many of the Linux tools would probably fail [most likely including compiling gcc with that compiler]. But you can't really say "on this architecture" or "in this OS" or "with this compiler" ... without also qualifying what the OTHER parameters are.

Case in point: A Microsoft C/C++ compiler has a long that is 32 bit even on 64-bit systems. Why, I hear you ask? Because a large number of Windows API functions use long as a 32-bit value as legacy from when Windows was a 16-bit OS on Intel 286/386 processors. Since (some of) the system calls are backwards compatible a very long way in Windows, code that is written for 16-bit systems will still work on 64-bit Windows [unless the code is using some really unusual system calls, and of course, the STYLE will look a bit ancient]. Changing long to a 64-bit value would have broken some of that functioanilty, so the compiler guys at MS decided to stick with long = 32 bit. If you want 64-bit integers, you have to use long long or int64_t or something else, not long. Of course, this breaks some code that assumes that sizeof(long) == sizeof(void *). Hopefully, most such code has already been fixed...