|
From: Behdad E. <be...@cs...> - 2006-06-02 19:27:55
|
On Tue, 30 May 2006, Nicholas Nethercote wrote: > On Tue, 30 May 2006, Ashley Pittman wrote: > > > On Tue, 2006-05-30 at 09:55 -0400, Behdad Esfahbod wrote: > >> On Tue, 30 May 2006, Ashley Pittman wrote: > >> > >>> On Sun, 2006-05-28 at 13:41 -0400, Behdad Esfahbod wrote: > >>>> Given that valgrind.h/memcheck.h > >>>> are suggested to be copied into user projects > >>> > >>> Is that true? As a header file surely it should be included via a > >>> #include line rather than copied and distributed with the user project. > >> > >> Yes, it is true. I certainly know how to #include a header! > >> Just read the second comment block in valgrind.h: > >> > >> /* This file is for inclusion into client (your!) code. > >> ... > > > > That was the comment I thought you were referring, I didn't take it to > > mean the files should be copied however, simply included via #include as > > needed. > > 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". 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. > Nick Thanks, --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" |