Hello
My question is, if I char a* = malloc(10); and then I free(a); how will free know the size of the data pointed to by a?
And is there any way to release a specific number of bytes in a given location?
Hello
My question is, if I char a* = malloc(10); and then I free(a); how will free know the size of the data pointed to by a?
And is there any way to release a specific number of bytes in a given location?
You can only free exactly what was malloced. The system may not actually keep track of the size directly (only indirectly by saying "the next available piece of memory is here"), or it might keep the size around somewhere.
It doesn't really matter, in practice, unless you are implementing malloc() and free(). All you need to know is that .... it does.
One way is that malloc() (and related functions) maintains some table that keeps track of what memory has been allocated, and the size of each chunk.
Another way is that malloc() uses some function provided by the operating system, and the operating system keeps track of what memory it has allocated for your program (or process).
Either way, something has to keep track. One reason that invalid operations on pointers often result - later - in a crash during a free() call is that the invalid pointer operation trashes a random area of memory. If that memory happens to correspond with some table that malloc()/free(), or the operating system, use to keep track of allocated memory, then hell breaks loose.
Generally, no.
As everyone has told you, this is not defined by the standard and is left up to the individual implementation; hence there are multiple right answers. If you want to take a look at individual implementations to get an idea of how it works you could read through:
That should get you started on providing some details behind what others have already answered. Beyond just academic curiousity though, there really is no reason into looking into how it works as grumpy has said.
Actually it's left to the Operating System, Andrew.
In windows the underlying HeapAlloc() and HeapFree() respectively build and remove structs forming a linked list that frames each allocation. To free memory, simply connect the struct before to the one after and set the pointer to NULL. Depending on the version of windows these structs keep a pointer to the previous block, a pointer to the next block and the size allocated. The returned pointer seen by application programs is actually to the end of the struct (the first available byte of the block) so when you free() memory it simply indexes -sizof(struct) and NULLS the pointers.
This is one of the reasons why it's a real bad idea to distube the first pointer from malloc(), if you increment it away from the point where it knows how to find the struct, free() fails and your program leaks memory.
Last edited by CommonTater; 09-08-2011 at 05:45 PM.
At some level it is always true... The OS has to martial out memory to applications and processes. If it were otherwise you'd end up with multiple processes accessing the same memory segments and all the fun that would cause. No matter that you've written your own memory manager (which is totally possible in C) at some underlying level you had to get that block of memory from an Operating System call... at which point the process becomes highly dependent on the OS.
You're assuming all developed software is hosted on an operating system, Tater. Try writing or maintaining an application that runs "on the metal" (i.e. interfaces directly to hardware with minimal or no intervening operating system) and you will find the application, or library it uses, has to deal with aspects of the "fun" that you describe.
Modern operating systems came to exist because of that recurring "fun" people had developing large software systems that had to interface directly to hardware. All that happens now, mostly, is that the fun is left for those who write the operating systems. But there are still examples of modern software being developed without benefit of being hosted on an operating system, even though a lot of people try to pretend otherwise.
For the purposes of this thread yes it'd be a true statement.
Most of those "baremetal" types aren't multitasking systems so having a memory manager is irrelevant since there's no translation involved; it's all physical.
Are you implying MS-DOS