> 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.)

I agree with you. We tried using valgrind, purify and numerous other
softwares. The applications I work on are huge multi-threaded,
multi-platform shared library plugins that are loaded by webservers
(Apache, IIS, Sun ...). We haven't come across a good tool that can
check for memory problems etc. Hence we developed in-house memory mgmt
routines that can check for leaks, bounds checking etc. It would make
sense for us to separately check for memory problems in all third party
libraries we use (curl etc.) These callbacks provide a way for us to
hook in our routines and check for API mis-use, memory problems etc.

BTW Dirk: I really doubt this would make the curl library bloated.

Regards
-Seshubabu Pasam
Received on 2004-04-06