C free memory on stack

Question

I created some utilities which help me to handle the management of a DinamicList. In the section that I use to handle the removing of a element in a list, if there is a element added that is stored in the stack, when I call free() an undefined behaviour is reached.

Surfing on the net I found out that there aren't ways to determine whether a pointer points to stack memory or heap memory.

So I think that to solve this problem I have to handle the error generated from free(). Is there a way to handle that exception when I call free()?

Americanism

No. C assumes you maintain enough state to know where each pointer points. free() isn't required to detect any error. Some implementations detect some kinds of errors, but your code shouldn't rely on this. – Birthroot

Either make a copy of every item passed to your code and take responsibility for freeing it, or don't make a copy of any item passed to your code and make the caller responsible for freeing it (if appropriate) when the list is released. You can't afford to have a mixture of dynamically allocated and stack allocated memory in your list if you are responsible for releasing the memory. – Catabolite

Answer 1

No.

You need to not call free() for non heap pointers. Easiest way is let whoever allocated the memory take care of freeing it. I.e. your utilities look after whatever memory they allocate but someone else looks after the memory passed to your utilities.

Motet

Answer 2

Although "malloc" and "free" are described in terms of creating allocations and destroying them, their actual role is the reverse of that. The "malloc()" function takes some memory from a pool and indicates that the memory manager is not allowed to use any of the bytes within the allocated range (though bytes that were outside that range, including those immediately preceding and following the allocation, remain available to it). The "free()" function adds memory back to the pool, making it available for future use.

In some allocation systems, the function that releases memory accepts an argument indicating how much memory is being released; others may require that each pool only be used to dispense fixed-size objects. Some of the systems that do such things would allow code to add any chunk of memory that a program won't need for any other purpose to a pool by simply "releasing" it, the memory manager knowing or caring whether the memory came from the pool in the first case. Indeed, in some such systems that may be how the pools get created in the first place: initialize a descriptor for an empty memory pool, and then "release" chunks of storage into it as convenient.

Such an approach to adding storage to a memory pool can't work in C, however, since the only way "free" can know how much memory to add to the pool is to make use of information that was stored somewhere by "malloc". Generally, the information is stored in the space immediately prior to the storage malloc() gives the application. If a pointer wasn't produced by malloc(), the storage immediately preceding the storage described by the pointer won't contain the information malloc() needs, but will more likely contain a pattern of bytes that looks like it was created by an allocation of some meaningless size. This would have the effect of inviting the memory manager to do whatever it likes with a large chunk of storage that will likely extend beyond the boundaries of the object whose address was passed to it. Hilarity is likely to ensue when the memory manager takes the application up on that invitation.

Acquittance

Answer 3

You may want to use _malloca and _freea. This way the system determines whether to allocate on stack or heap for you.

Sneer