Re: [Valgrind-users] Handling MALLOCLIKE inside a malloc'ed block

[Ashley P. <as...@qu...>]

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.

> I'm wondering what
> stability promises do valgrind make.  Or for example, if this new
> hint is added, is there a way to detect that and not enable the
> hints if the new hint is not available?

There are two issues here, firstly there was a major change (in
practical terms at least) where Julian changed the magic for making
client requests, there is now a "old method" and a "new method", the new
code coming into force with r5603 in February.

The client requests themselves did not change at this time, merely the
underlying magic sequence so the same client code will work with either
set, as long as it was compiled with the correct header for the running
version.  This is a good reason for not shipping your own copies of the
valgrind headers.

As regards promises about stability, I certainly noticed and raised it
on the list (I'm a valgrind user, not a developer) when this change was
made, the consensus at the time was that the need for a ABI wasn't
something that had been considered up to that point.  Effort was taken
at that time to ensure that the new method was future-proof so there
should be no need for more changes if future.

The second issue is the question of how to tell if a specific hint is
supported, most of them have a return code of 0 if not running on
valgrind and 1 for success, other values for different error cases.
Valgrind itself gives a warning to the user if you make a client request
it doesn't know about.  All the client requests return 0 if you are
using the wrong headers.

Ashley,