Data type consistency

Why when we allocating memory block using (ma|re|c)alloc we use sizeof([count *] primitive data type)?

E.g.

Code:

---

int *a = malloc(5 * sizeof(int)); //allocating 5 blocks of int

---

Instead of

Code:

---

#define INT_SIZE 4
int *a = malloc(5 * INT_SIZE);

---

But, I'm not talking about

Code:

---

#define int char

---

Is there possibility that sizeof(int) could be changed to (for example) 2 or 16?

Yes, the size of int may be different on different platforms.

Incidentally I believe this is even more better:

Code:

---

int* p = malloc(5 * sizeof(*p));

---

This way, should you change the variable type you won't end up with:

Code:

---

short* p = malloc(5 * sizeof(int));

---

The size of int depends on the processor (changes between different architectures - 16bit processors = 2 bytes, 32bit = 4 bytes, 64bit = 8 bytes, and this will be the size of the memory registers and others)
Although some people told me it depends on the compiler (they showed me a proof - compiled sizeof(int) in Borland CPP and on Dev CPP and the results were different - 2 for Borland and 4 for Dev CPP)

Quote:

---

Originally Posted by eXeCuTeR

Although some people told me it depends on the compiler (they showed me a proof - compiled sizeof(int) in Borland CPP and on Dev CPP and the results were different - 2 for Borland and 4 for Dev CPP)

---

I would imagine that the Borland compiler was of the fossil variety (compiled only 16-bit executables). Which is why sizeof(int) was 2.

Quote:

---

Originally Posted by swoopy

I would imagine that the Borland compiler was of the fossil variety (compiled only 16-bit executables). Which is why sizeof(int) was 2.

---

Do you have any proof that it depends on the processor? I gotta figure what's right.

It depends more on the compiler than the processor. Sure, different processors have different optimal data sizes, but it's the compiler that makes the decisions. For example, 32-bit processors can use 64-bit data types, too, just a bit slower.

On all current x86-64 compilers I know and/or have used, both on 64-bit Windows and 64-bit Linux, sizeof(int) is still 4, for backward compatibility.

It should depend on both, but int is intended to be the "native" integer size -- that is the size that the processor is built to handle most efficiently. For your typical Intel x86 processor that's 4 bytes. But it is up to the compiler to determine what that native size is, and principally it could be configured differently than expected.

Quote:

---

Originally Posted by anon

Yes, the size of int may be different on different platforms.

Incidentally I believe this is even more better:

Code:

---

int* p = malloc(5 * sizeof(*p));

---

---

Unless p == NULL, in which case *p will blow up.

why so?

Code:

---

#include <stdio.h>

int main() {
        int *p = NULL;
        printf("&#37;d", sizeof(*p)); // 4
}

---

works for me. (32-bit Linux, gcc 4.1.2)

Quote:

---

Originally Posted by cpjust

Unless p == NULL, in which case *p will blow up.

---

What happens if p points to null? *p will still remain as an int, wouldn't it?

The sizeof operator is special in this case, I believe, since it's macro. No actual dereferencing is really taking place afaik.

Quote:

---

Originally Posted by cpjust

Unless p == NULL, in which case *p will blow up.

---

sizeof is a language keyword, and not a function (it's an operator). Specifically,

Quote:

---

Originally Posted by Standard, C89

The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand, which is not itself evaluated. The result is an integer constant.

---

sizeof(*p) will work as it should.

> #define INT_SIZE 4
Well if you did
#define INT_SIZE sizeof(int)
It would be better.

> Unless p == NULL, in which case *p will blow up.
The only 'dereference' is through the compiler's expression tree to find the type of *p, and thus work out the size of the required object. Nothing happens at run-time, except to multiply by the constant which the compiler determined to be the size of a *p

Quote:

---

Originally Posted by Salem

> Unless p == NULL, in which case *p will blow up.
The only 'dereference' is through the compiler's expression tree to find the type of *p, and thus work out the size of the required object. Nothing happens at run-time, except to multiply by the constant which the compiler determined to be the size of a *p

---

Thanks, I'll have to test that and see, but it's good to know.

Quote:

---

Thanks, I'll have to test that and see, but it's good to know.

---

If your test fails, then the compiler does not comply with both the C89 and C99 editions of the C standard.