The other solution is to not support user callbacks for debug version.
The user callback function will be implemented but will be a no-op. I am
not sure this approach will have many takers :-)

Regards
-Seshubabu Pasam

Seshubabu Pasam wrote:
>
> I stumbled on an issue. curl_domalloc ... functions take three arguments
> where as malloc takes one. There is a function signature mis-match.
> Here is sample code:
>
> Hearder file:
> -------------
> typedef void *( *curlMallocFunc ) ( size_t size );
> extern curlMallocFunc curl_malloc;
> #define malloc( x ) curl_malloc( x )
>
> C code:
> -------
> #ifdef CURLDEBUG
> curlMallocFunc curl_malloc = curl_domalloc; /****** PROBLEM ******/
> #else
> curlMallocFunc curl_malloc = ( malloc );
> #endif
>
> The solution is to do the following, but it adds a level of indirection.
>
> C code:
> -------
> typedef void *( *curlInternalMallocFunc ) ( size_t size,int l,char *f );
>
> #ifdef CURLDEBUG
> curlInternalMallocFunc curl_malloc = curl_domalloc;
> #else
> curlInternalMallocFunc curl_malloc = curl_internal_malloc;
> #endif
>
> void *curl_internal_malloc ( size_t size, int l, char *f ) {
> return curl_user_callback_malloc ( size );
> }
>
> Any solutions/suggestions/preferences?
>
> Regards
> -Seshubabu Pasam
>
> Daniel Stenberg wrote:
>
>> On Fri, 7 May 2004, Seshubabu Pasam wrote:
>>
>>
>>> Are you saying you want this to be enabled by default, but have an
>>> option to
>>> turn it off? Or there is no need to have ability to disable this
>>> feature?
>>
>>
>>
>> The penalty of using function pointers for these functions always is very
>> little so I prefer to have them so, yes.
>>
>>
>>> It will definitely make the patch much easier, if the standard function
>>> names can be kept. Yes there is the issue of someone sneaking in code
>>> with
>>> malloc/free etc. I figure there is an interesting way to do this.
>>
>>
>>
>> That happens most commonly when someone provides a good patch and the
>> reviewers (like me) miss that there's a function call in there that is
>> used
>> when it shouldn't be. It has happened many times before, so I like to
>> reduce
>> that risk.
>>
>>
>>> But then we will still have to rename some functions (like the free in
>>> url.c where the memory is allocated by libIDN).
>>
>>
>>
>> We already have that fixed, as you can see. The memory debug system
>> already
>> works, and that works by redefining those functions to use other
>> functions.
>>
>> [calloc]
>>
>>> I guess that mean one more callback function!
>>
>>
>>
>> Yes: malloc, calloc, realloc, strdup, free
Received on 2004-05-08