On Apr 4, 19:26, "codemastr" wrote:
>I just don't see what is wrong with libcurl's builtin memory debugging
>functions. I mean, if he finds a memleak in libcurl, most likely Daniel is
>going to be the one who finds/fixes it. So wouldn't it make sense to have
>the memory debugging information in the format that Daniel wants?

Obviously if the idea was to just do basically the same as the builtin
memory debugging, then yes, adding another mechanism would just be overkill.
But my understanding was that it was wanted for some other purpose (integrating
with their own system, IIRC). I'm a bit behind on my email at the moment
(on mission in Sweden), let me just check the web mailinglist archive for
a moment.. ok, it looks like Daniel has given a partial go-ahead already.
(A note for Dirk btw.. valgrind runs only on i386 Linux, on lots of other
platforms there are no free tools available whatsoever, sometimes not even
any commercial tools. And the latter will cost you your firstborn. On AIX
for example, the prices for the commercial tools (e.g. ZF, a CPU synthesizer
similar to Valgrind) are in the order of tens of thousands of dollars for
a very limited site license.)

-Tor
Received on 2004-04-05