Re: Removing libc allocation and string function wrappers

On 12/18/2017 6:06 AM, Michael Stahl wrote:
> On 18.12.2017 03:24, Michael McConville wrote:
>> Hi guys.
>>
>> Hopefully this doesn't sound presumptuous coming from an outsider, but I think
>> you could benefit from removing some or all of your wrappers for libc functions
>> like malloc. Modern platforms offer many tools for tracing and debugging
>> allocations, which seems to be the motivation for the wrappers. The semantics
>> of these wrappers seem to be identical to the POSIX semantics, so replacement
>> would be easy.
> 
> well there are not only POSIX systems out there: on Windows, it's
> possible to have multiple different malloc/free implementations and
> therefore heaps in the same process, and care needs to be taken to
> ensure that the objects allocated by a particular malloc() are passed to
> the corresponding free() and not to a different one.
> 
> one way to do that is to export free_* wrapper functions from your DLL
> so the client never calls free directly; all the allocation and
> deallocation calls of types provided in the library are done in the DLL
> itself through wrapper functions, which are guaranteed to work on the
> same heap.

This is true even on Linux if the client chooses to use a different
runtime library, e.g. newlib, instead of the native OS runtime library.
It's just worse on Windows as each VS compiler version distributes a
different runtime library.

-- 
Earnie