In message <20140422041806.GA42772@???>, Phil Pennock
<pdp@???> writes
>On 2014-04-21 at 13:29 +0100, Richard Clayton wrote:
>> ... it would be good to address these whilst creating #4.83. The missing
>> US in malware.c has already been fixed, but we need some casts in
>> store.c.
>>
>> I see that bug 1145 already noted this (in Sep 2011) ... and the patches
>> are obvious (too obvious ?):
>
>My understanding has been that the valgrind stuff disappears with
>NVALGRIND defined in Local/Makefile and that the problems were somehow
>inherent in using Valgrind.
what disappears with NVALGRIND is stuff within valgrind.h, but these
macros are defined in memcheck.h and they are always the same (it's just
that what the guts of them do differs)
ie: you get the same clang warnings whichever way this flag is set
>If instead Valgrind can be fixed with casting results to void, why
>aren't these part of the macro definitions?
ah... <fx: more searches> I think they may have fixed this upstream:
M
http://valgrind.10908.n7.nabble.com/Valgrind-r13595-trunk-drd-drd-
qtcore-intercepts-c-td47094.html>
But note that the files have been slightly customised when pulling them
into Exim ... so will take a little while to check for sure
>I'm not arguing against these changes, merely taken aback that the
>solution to those valgrind complaints might turn out to be so simple.
:)
--
richard Richard Clayton
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
