Use of sizeof operator in C

Question

I wrote a code to print size of different data types in C .

#include<stdio.h>
int main()
{
     printf("%d", sizeof(int));//size of integer
     printf("%d", sizeof(float));
     printf("%d", sizeof(double));
     printf("%d", sizeof(char));
}

This does not work , but if I replace %d with %ld , it works. I did not understand why I have to take long int to print a small range number.

Answer 1

Both of those are wrong you must use %zu to print values of type size_t , which is what sizeof return.

This is because different values have different size, and you must match them.

It's undefined behavior to mismatch like you do, so anything could happen.

Answer 2

This is because sizes mismatch. By either using %zu or using %u and casting to unsigned you may fix the problem.

Currently, your implementation is undefined behaviour.

 printf("%u", (unsigned)sizeof(int));//size of integer
 printf("%u", (unsigned)sizeof(float));
 printf("%u", (unsigned)sizeof(double));
 printf("%u", (unsigned)sizeof(char));

Since stdout is new line buffered, don't forget to print \\n at the end to get anything to screen.

Answer 3

sizeof has the return type size_t . From the Standard,

6.5.3.4  The sizeof and _Alignof operators

5 The value of the result of both operators is implementation-defined, and its type (an unsigned integer type) is size_t, defined in <stddef.h> (and other headers).

size_t is implementation-defined. In my linux, size_t is defined as __SIZE_TYPE__ . On this topic, one can find details here .

In your case, it happens that size_t is implemented as a long , longer than int .

Answer 4

I did not understand why I have to take long int to print a small range number.

Because size_t may represent values much larger than what an int can support; on my particular implementation, the max size value is 18446744073709551615 , which definitely won't fit in an int .

Remember that the operand of sizeof may be a parenthesized type name or an object expression:

static long double really_big_array[100000000];
...
printf( "sizeof really_big_array = %zu\n", sizeof really_big_array );

size_t must be able to represent the size of the largest object the implementation allows.

Answer 5

You say it does not work , but you do not say what it does. The most probable reason for this unexpected behavior is:

• the conversion specifier %d expects an int value. sizeof(int) has type size_t which is unsigned and, on many platforms, larger than int , causing undefined behavior.

The conversion specifier and the type of the passed argument must be consistent because different types are passed in different ways to a vararg function like printf() . If you pass a size_t and printf expects an int , it will retrieve the value from the wrong place and produce inconsistent output if at all.

You say it works if I put %ld . This conversion may work because size_t happens to have the same size as long for your platform, but it is only a coincidence, on 64-bit Windows, size_t is larger than long .

To correct the problem, you can either:

• use the standard conversion specifier %zu or
• cast the value as int .

The first is the correct fix but some C libraries do not support %zu , most notably Microsoft C runtime libraries prior to VS2013. Hence I recommend the second as more portable and sufficient for types and objects that obviously have a small size:

#include <stdio.h>

int main(void) {
    printf("%d\n", (int)sizeof(int));
    printf("%d\n", (int)sizeof(float));
    printf("%d\n", (int)sizeof(double));
    printf("%d\n", (int)sizeof(char));
    return 0;
}

Also note that you do not output a newline: Depending on the environment, the output will not be visible to the user until a newline is output or fflush(stdout) is called. It is even possible that the output not be flushed to the console upon program exit, causing your observed behavior, but such environments are uncommon. It is recommended to output newlines at the end of meaningful pieces of output. In your case, not doing so would cause all sizes to be clumped together as a sequence of digits like 4481 , which may or may not be what you expect.