-2

I heard that free() could release less memory than malloc() took, because malloc takes memory in x8 bytes. An example : if I wanted 20 Bytes so malloc gave me 24 and when I use free it gives back the 20 bytes and the (24 - 20) bytes are left no free. Is it true?

A.Shoob
  • 9
  • 2
  • 4
    From where did you get this? – babon Dec 07 '19 at 06:21
  • That would not be standard behavior. malloc may allocate a larger block, but freeing it just marks that block as available to return in a future request. most implementations would have that be part of a much larger block (4kB or more) allocated from OS. – Garr Godfrey Dec 07 '19 at 06:25
  • If you have the original reference you should provide that. You may be misunderstanding what was being said. It is true that `free` may not immediately return the memory to the OS as it tries to be smart about preventing fragmentation. But that is not the same as what you seem to be saying. – kaylum Dec 07 '19 at 06:26
  • 1
    Does this answer your question? [How do malloc() and free() work?](https://stackoverflow.com/questions/1119134/how-do-malloc-and-free-work) – kaylum Dec 07 '19 at 06:27

1 Answers1

2

That would be a spectacularly bad implementation of memory allocation functions and, in fact, the standard (referencing C11, the current standard in force) appears to disallow it (I'm activating "language lawyer" mode here):

The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation.

The space pointed to is the whole space so, if you can only use part of it, that's not really following the standard. Now you may think you could argue that it only has to free the space taken by the size you specified but I don't believe that's the case. In malloc, it states:

The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate. The malloc function returns either a null pointer or a pointer to the allocated space.

Note that phrase "allocated space" mirroring the "space pointed to by" phrase in free - I believe that refers to the entire allocated chunk even though, if it's bigger than what you asked for, you should not use the excess (in fact, you don't even know there is excess).

Reading those two quotes in conjunction seems to indicate it must free the lot.

But, as stated earlier, and language lawyering aside, any implementation that actually did what you posit would be very short-lived as it consistently crashed from lack of memory caused by memory leaks.

Or, in a less nerdy context, when I ask to borrow your lawnmower and you also give me your hedge-trimmer out of the kindness of your heart, I suspect you wouldn't be happy to find out I've listed the latter on eBay because I assumed that, since I hadn't asked for it, you didn't need it back :-)

Also, as an aside re your "malloc takes memory in x8 bytes" comment, that is by no means a given.

For example, I have in the past implemented allocation functions in embedded systems where x bytes was given regardless of what value not greater than that was asked for (obviously, if you asked for more, it just failed).

This allowed for optimisations in situations where you knew allocations should never be larger than that.

So, while you'll frequently find implementations that impose a certain resolution (be it eight bytes, sixteen or some other size), that's by no means mandated.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • What's mandated is that the alignment of the storage is suitable for *any* object. If the platform has no alignment requirements, then you're Ok; otherwise, the amount of space reserved must be a multiple of the largest alignment required by any standard type, no? – rici Dec 07 '19 at 07:18