On 2025-01-18 Bruno Haible wrote: > Valgrind was a tool without replacement, for many years, when > sanitizers did not exist. Nowadays, however, I generally prefer > testing with sanitizers than with valgrind because there are some > bugs that ASAN finds and valgrind doesn't [1]. For example, when you > have a struct with two adjacent arrays, ASAN can find buffer overruns > of the first array, while valgrind can't. Just this week, sanitizers > have found a real bug in coreutils [2]. > > Regarding your trick to do an aligned read on (addr & -alignment) > instead of an unaligned read on (addr): I find it good that ASAN > catches this, because this trick amounts to exploiting a coincidental > property of current hardware.
I agree. One could mark the tricks so that sanitizers skip them. There are attributes to do that but those can make people suspicious that one is trying to prevent fuzzers from finding security issues. Writing extra code to keep sanitizers happy is the alternative. Intrinsics usage is already platform specific (in practice at least) so doing platform specific tricks should be possible somehow because it can be more convenient to write with intrinsics than assembly. Inline assembly also avoids sanitizers. It doesn't look as suspicious as attributes that disable sanitizers so people are happier (as long as they don't realize this). > Similarly to accessing (addr + (1 << n)) for 48 < n < 64: some > hardware allows this, but it's an ISO C violation nevertheless. That wouldn't be a good idea in assembly code either. -- Lasse Collin
