Re: [Valgrind-developers] Proposed valgrind division patch

[D. J. B. <dj...@cr...>]

Paul Floyd via Valgrind-developers writes:
> Using VALGRIND_OPTS is clunky but I think that we should stick to that.

To explain why the new environment variable is easier to use: It's a
"best-effort" variable that's simply ignored by older versions of
valgrind. The data-collection script that uses the variable doesn't have
to worry that it will fail under older versions. Without the variable, I
think the easiest path for the script would be to parse the output of
valgrind --help-dyn-options to see whether the option is listed, and to
then set the option or not accordingly; sure, can be done, but it's more
of a hassle.

There's already one option-setting mechanism that's best-effort (with a
minor difference in verbosity), namely VALGRIND_CLO_CHANGE, but that's
called by the binary rather than by the script calling valgrind.

John Reiser writes:
> How much more effective is the dynamic technique than such a
> static analysis?

https://www.usenix.org/system/files/usenixsecurity24-fourne.pdf is a
usability study of tools to look for timing variations; a valgrind-based
tool ranks best---and that's without covering the CI situation, where
the differences in tool usability become even more obvious. Of course,
valgrind tests only the code paths that it runs, whereas static analysis
can give full-program guarantees. For more on the advantages of each
approach: https://kyberslash.cr.yp.to/kyberslash-20240628.pdf#section.7 

---D. J. Bernstein (speaking for myself)