Hmmm! Not exactly sure, how your suggestion would work! efence from what
know, does mmap to allocate/manage memory. So it completely replaces
malloc/free/realloc implementations ... In our case we are not
completely replacing malloc/free/realloc etc. We are just wrapping them
in our own functions and doing some checks for bad stuff.

 From what you are suggesting I will have to implement a method called
"malloc" in our application and within that function, some how call
libc's "malloc".

Regards
Seshubabu Pasam

Tor Arntsen wrote:
> On Apr 3, 23:51, Seshubabu Pasam wrote:
>
>>CURLOPT was just a suggestion. Typically this is done like this:
>>
>>typedef void *( *curlMalloc ) ( size_t size );
>>typedef void ( *curlFree ) ( size_t size );
>>typedef void *( *curlRealloc )( void *mem, size_t size );
>>typedef char *( *curlStrdup ) ( const char *str );
>>
>>curlMalloc curl_malloc = malloc;
>>curlFree curl_free = free;
>>curlRealloc curl_realloc = realloc;
>>curlStrdup curl_strdup = strdup;
>>
>>void curl_set_memory_callbacks ( curlMalloc m,
>> curlFree f,
>> curlRealloc r,
>> curlStrdup s ) {
>> curl_malloc = m;
>> curl_free = f;
>> curl_realloc = r;
>> curl_strdup = s;
>>}
>
> [...]
>
> Personally I in general like having "hooks" like this, but in the case
> of malloc/free/realloc/strdup I don't think it is necessary. For libc
> functions you can always just re-map them the way e.g. ElectricFence does
> it, i.e. just write your own malloc/free etc. put them in a library, add link
> with it. Your functions will be used instead of the system provided functions.
>
> -Tor
Received on 2004-04-04