|
From: Nicholas N. <nj...@cs...> - 2006-06-03 01:04:25
|
On Fri, 2 Jun 2006, Behdad Esfahbod wrote: >> Behdad, I can think of three possible ways of incorporating valgrind.h: >> >> 1. copying it directly into a C file (clearly silly) >> 2. making a local copy in your project and #include'ing that >> 3. #include'ing the installed copy from $INSTALL/include >> >> Number 3 is the intended method. Are you doing number 2? It's not clear to >> me because if you do number 3 I don't see why you should have problems with >> version mismatches between valgrind.h and the Valgrind program. > > Ah, ok. Yes, I was doing number 2, and the gslice maintainer had > my same reading of "for inclusion into client (your!) code". It turns out the manual recommends #2. Hmm. > BTW, I'm willing to work on a patch to make MALLOCLIKE inside > malloc'ed block work, should you tell me what kind of approach > you prefer. My IGNORE_HEAP_BLOCK approach is flawed because it didn't handle freeing of the superblock. One possibility would be to introduce IGNORE_NEXT_MALLOC and IGNORE_NEXT_FREE requests, which would do the obvious thing. They're simple (no arguments!) which is good, but they're stateful, which is not so nice. You mentioned having a valgrind.h versioning system to avoid the problem of a Valgrind possibly having MALLOCLIKE/FREELIKE but not IGNORE_*. Better I think would be another request SUPPORTS_IGNORE_REQUESTS. You could query that first. Version numbers are a pain, because they're arbitrary, and it's easy to forget to update them. (We've found that with the internal core/tool versioning system we have.) Nick |