2

I have researched in all possible ways I could but it's hard for me to digest the fact that both malloc i.e.malloc(sizeof(10)) and calloc i.e. calloc(2,sizeof(5)) allocates same contiguous memory, ignoring the other facts that calloc initializes to zero and works relatively slower than malloc. so this is what I think.

I think that on a 32-bit system if we call malloc and say malloc(sizeof(10)) then malloc will go to the heap and allocate 12 bytes of memory, because for a 32-bit system the memory packages are arranged in groups of 4 bytes so to allocate 10 bytes 3 blocks are needed with a padding of 2 bytes in the last block.

Similarly, if we call calloc and say calloc(2,sizeof(5)) then it will allocate 2 blocks each of size 8 bytes and in total 16 bytes because due to the same reason that memory is in the packages of 4 bytes and to allocate 5 bytes two blocks of 4 bytes are used and in one block a padding of 3 bytes will be provided.

So this is what I think of malloc and calloc. I may be right or wrong but please tell me either way.

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
Ashish Dogra
  • 593
  • 4
  • 13
  • 5
    *malloc(sizeof(10)) and calloc i.e. calloc(2,sizeof(5)) allocates same contagious memory* - that's simply false. Maybe you meant `malloc(10)` and `calloc(2,5)` ? – Eugene Sh. Dec 14 '17 at 18:13
  • The exact behavior of these functions is implementation defined. It could do what you stated, or something entirely different. From the standpoint of the C developer, it doesn't matter. – dbush Dec 14 '17 at 18:15
  • 1
    @EugeneSh. yup exactly. – Ashish Dogra Dec 14 '17 at 18:20
  • `"calloc initializes to zero and works relatively slower"` - the *"relatively slower"* is negligible and in almost all cases when allocating for arrays, etc.., the benefits of preventing an inadvertent read from an uninitialized value far out weights any relative difference in allocation speed due to initialization of all bytes to zero. – David C. Rankin Dec 14 '17 at 18:29
  • 1
    C library interfaces work the way they are documented to work. Your desires, beliefs, and esthetic judgements do not alter the behaviour. – rici Dec 14 '17 at 18:30

2 Answers2

7

calloc allocates "memory for an array of nmemb elements of size bytes each" (Linux man page), but we know that arrays in C cannot have padding between array elements, they must be contiguous in memory. On the other hand, malloc allocates "size bytes", so either of malloc(10) or calloc(2,5) will give you those ten bytes.

Now, what happens behind the scenes is another issue, the C library might decide to allocate 12, 16, or 42 bytes instead. But you can't and must not count on that. If you ask for 10 bytes, assume you got 10.

malloc(sizeof(10)) is different, it takes the size in memory of an int (since 10 is an int), and allocates that much.

ilkkachu
  • 6,221
  • 16
  • 30
1

What you get when you use both methods is at least that amount of memory you request. It can be more. One reason could be the one you are mentioning. Another reason can be that you get a bigger chunk just in case you want to change it later.

There's no way to say exactly how much you got. Only that you are guaranteed at least what you requested, and if you don't, you'll get a null pointer.

Note though, that with get I mean that you get what you ask for, and you can NEVER count on more than that. That will be undefined behavior.

klutt
  • 30,332
  • 17
  • 55
  • 95
  • 2
    No it is not. What you're saying may sound reasonable and may or may not even be likely, but you don't have any guarantees at all. You can only count on the amount you requested. – klutt Dec 14 '17 at 18:28
  • 1
    This answer is wrong. What you get is exactly what you ask for. It may happen to be that, due to implementation details, there is additional unused space *adjacent to your allocation* that happens not to clobber anything else if you write to it, but it is not part of your allocation, and accessing it invokes undefined behavior. This distinction may be observable especially with hardened compiler options (like GCC's or LLVM's sanitizers) where accessing it might trap. – R.. GitHub STOP HELPING ICE Dec 14 '17 at 18:54