# Thread: malloc question..

1. ## malloc question..

hat the plus 4 means in the last part
how it change the number of cells in the "i" row??

Code:
```int **arr;
arr=(int**)malloc(... )
for i=0..
arr[i]=(int*)malloc(sizeof(int)+4);```

2. You should *REALLY* learn to read manuals. Why don't you try searching for example for "man malloc" with google?

3. i know that if its *4 then
4 cells

what if +4
??

4. read the documentation of malloc as I said. It tells what the sole argument of malloc means.

5. i know what it means .
i know that +4 means adding 4 bits

how it change the number of cells in the "i" row??

6. It does not add 4 bits. It adds 4 bytes.

And you get the answer when you think how many bytes one item in your array needs.

7. integer is 8 bytes
so it doesnt add any new cells??

8. there's not a fixed size for int. It's usually 4, but can be different in other systems. That's why sizeof() exists, it's a function that returns the size (in bytes) of a data type.

9. integer is 8 bytes
so it doesnt add any new cells??
It's 8 bytes on a 64-bit system. It's 4 bytes on a 32 bit system.

We can't really tell you if it adds new cells. The call just returns a pointer to a certain area in memory equal to the size you specified. It's impossible to tell if that's what you want and what you mean by adding cells - because it depends on how you work with that area of memory.

You should *REALLY* learn to read manuals.
Why don't you, by the way? You've been asked this many times, and you seem to make no improvement towards helping yourself.

10. Actually, integer is standardized to 4 bytes. But pointer to integer may be 4 or 8 bytes (or something else) depending on the machine's architecture.

11. Originally Posted by Maz
Actually, integer is standardized to 4 bytes. But pointer to integer may be 4 or 8 bytes (or something else) depending on the machine's architecture.
No it's not. I've used systems where an integer has been 8 bits, 16 bits, 32 bits, and 64 bits.

12. Originally Posted by Maz
Actually, integer is standardized to 4 bytes. But pointer to integer may be 4 or 8 bytes (or something else) depending on the machine's architecture.
Not standardized... Just common. Most compilers I've used on x86-64, for instance, default to a 32-bit integer type (you must specify "long long" to get 64 bits) but this is not specified by the standard.

Other 64-bit architectures I've worked with default to 64-bit integers. Sometimes the compiler lets you select.

You should not assume anything, especially when somebody can change it via compiler switch.

13. Originally Posted by bithub
No it's not. I've used systems where an integer has been 8 bits, 16 bits, 32 bits, and 64 bits.
Youre right. int size is not standardized. Apologies

I guess I should use uint32_t from now on (as if it was supported by all libraries...)

14. Doesn't that standard say that int is the natural word size of the processor? In other words, a pointer and an int should always be the same size? And a 64-bit compiler should always make a 64-bit int?

That's what I understood, but it sounds like I'm mistaken?

15. I won't say a word about standard anymore But that really is not the case. I've been doing some hell of a porting work to get pointer arithmetics working after we changed from 32bit arch to 64 bit arch... (there were pointers casted to ints, and then calculated some offsets && casted them back. Also we had some ID numbers for things, and actually those IDs were then used as memory locations... A mess...

Popular pages Recent additions