For more time than git existence ;-) our MemoryTracking builds do a
neat job in detecting memory leaks. But currently we are also carrying
along something that I believe might be counterproductive at least in
certain scenarios.

I'll try to be as clear as possible...

When MemoryTracking is enabled, besides very useful actual resource
de/allocation accounting our (memdebug.c) internal curl_domalloc(),
curl_docalloc() and curl_dofree() replacements for malloc(), calloc()
and free() do some extra 'magic'. I'm omitting other details on
purpose to concentrate on what I want to emphasize here.

1) curl_docalloc() calls system's malloc() and fills memory with zeros.

Doing this would at most benefit buggy system calloc() implementations
that do not zero out memory. Does such a bug exist somewhere? In any
case, when built with MemoryTracking disabled system's calloc() would
be used. Does someone remember if there's a reason to not call
system's calloc() directly and instead do the malloc() plus zero fill?

1) curl_domalloc() calls system's malloc() and fills memory with a
given value, currently 0xA5.

Doing this helps those debugging libcurl in being capable of repeating
the same code path due to uninitialized variables when dynamically
allocated. But additionally it renders useless valgrind and compiler's
runtime checks in detecting exactly uninitialized variables when
dynamically allocated (valgrind and compilers will get fooled into
thinking it has been initialized with 0xA5, eeek!).

3) curl_dofree() fills memory with a given value, currently 0x13, and
calls system's free().

Given that system's free() is finally called, filling it previously
serves little purpose.

Please also take in consideration that when finally using the
dynamically allocated memory we do not check its actual value against
our magic 0xA5 or 0x13, nor really have the opportunity of doing it.

So, given that it seems that having all this memory filling in place
represents little advantages and big drawbacks, could we...?

1) make curl_docalloc() call system's calloc() and remove the zero fill.

2) remove the magic 0xA5 fill from curl_domalloc()

3) remove the magix 0x13 fill from curl_dofree()

A collateral benefit would be that MemoryTracking enabled builds
should get a speed improvement due to less memory filling.

Patch attached with exactly the changes I'm proposing, which I
actually consider more a fix than a feature change.

If we want to be extremely cautious we could do this in two steps.
First the curl_domalloc() and curl_dofree() fixes in one shot, a full
day of autobuild runs, and afterwards the curl_docalloc() fix with
another full day of autobuilds.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html