While this package does contain a private copy of valgrind.h (and memcheck.h), as advised by the valgrind upstream, R in Fedora does not use that header, unless the --with-valgrind-instrumentation option is passed to configure with a value greater than 0. Since it is not, NVALGRIND is defined, and the header is never included into the R code at compilation.

That said, since it is hypothetically possible that we could turn on valgrind instrumentation in R at some point, I've worked up a patch to detect system valgrind headers and use them if present (and fall back to the local bundled files, if not). I've also asked upstream to merge in a copy of these two headers from valgrind 3.10.0.

https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16068

Since this doesn't affect Fedora, I'm closing this as NOTABUG, and will leave the decision on merging this change to detect valgrind system headers as needed to the R upstream.

(In reply to Tom "spot" Callaway from comment #1)
> While this package does contain a private copy of valgrind.h (and
> memcheck.h), as advised by the valgrind upstream

I don't believe valgrind upstream advises to just include private copies of these files. The header file contains the actual valgrind version number it corresponds to and might (as referenced) contain bug fixes in newer versions.

IMHO (I work on upstream valgrind) we should actively discourage that. Could you provide a reference to where upstream advises to create private copies of these files? Then I'll discuss with the other upstream developers what we really should advise.

From memcheck.h:

/* This file is for inclusion into client (your!) code.

   You can use these macros to manipulate and query memory permissions
   inside your own programs.

   See comment near the top of valgrind.h on how to use them.
*/

From valgrind.h:

/* This file is for inclusion into client (your!) code.

   You can use these macros to manipulate and query Valgrind's
   execution inside your own programs.

   The resulting executables will still run without Valgrind, just a
   little bit more slowly than they otherwise would, but otherwise
   unchanged.  When not running on valgrind, each client request
   consumes very few (eg. 7) instructions, so the resulting performance
   loss is negligible unless you plan to execute client requests
   millions of times per second.  Nevertheless, if that is still a
   problem, you can compile with the NVALGRIND symbol defined (gcc
   -DNVALGRIND) so that client requests are not even compiled in.  */

Also, you might want to chime in on that R bug, the R upstream says that the 3.10.0 macros are not the same as the older ones and that changing them out will take some time.

(In reply to Tom "spot" Callaway from comment #3)
> From memcheck.h:
> 
> /* This file is for inclusion into client (your!) code.
> 
>    You can use these macros to manipulate and query memory permissions
>    inside your own programs.
> 
>    See comment near the top of valgrind.h on how to use them.
> */
> 
> From valgrind.h:
> 
> /* This file is for inclusion into client (your!) code.
> 
>    You can use these macros to manipulate and query Valgrind's
>    execution inside your own programs.
> 
>    The resulting executables will still run without Valgrind [...]

Thanks. I can see why that might be read not as "These are #include files for non-valgrind-tools aka normal programs", but as "Include these files in your source tree". I believe we meant the first, not the second. I'll discuss with upstream how to better word this. We should probably split the include files anyway, so that the valgrind-devel package is split into a package for "client programs" and one to write your own "valgrind tools". Currently the different include files are packaged together, which adds to the confusion.

> Also, you might want to chime in on that R bug, the R upstream says that the
> 3.10.0 macros are not the same as the older ones and that changing them out
> will take some time.

Urgh. R seems to have included a copy from before valgrind 3.2.0. That is more than 8 years ago. And I am not even sure those client request macros really work against modern valgrind. Valgrind hasn't knowingly changed the interface/macros in an incompatible way (except for the ppc32 bug fix and new additions) since 3.2.0. I'll comment on the bug. Thanks.

BTW. We discussed this upstream and it was indeed recommended in the past. When valgrind was young people couldn't rely on it being packaged and available. These days however we like packages not to include a private copy and this should be documented: https://bugs.kde.org/show_bug.cgi?id=340889