>>>> I've opened the following PR to add support for GCC v5 and >>>> address sanitizer (not sure if we want valgrind as well...): >>>> https://github.com/openssl/openssl/pull/429 > > I've commented there on other -fsanitize options as well as about > option to execute them without --debug and/or --strict-warnings. But I > failed to recall all the details from last time the question was risen > in context of RT#3422 through 3324. -fsanitize=undefined is expected > to work only with --strict-warnings (or more specifically with > -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works > only with -DPURIFY.
The main weakness of the endeavour is that testing is limited to x86 hardware. I don't mean specifically -fsanitize, but in general. But let's concentrate on -fsanitize for a moment. Or more specifically why are there limitations for it, ones mentioned above. In the nutshell, remaining -fsanitize warnings were effectively about the fact that we sometimes rely on platform- or implementation-specific behaviour. But it is *conscious* choice and there always is platform-neutral fallback. So that above mentioned limitations are actually about nothing else but driving compiler toward these platform-neutral fallbacks. One can even take next step and say that in order to maximize -fsanitize utility, one should expose as much C code to -fsanitize as possible, or in other words adhere even to no-asm with -fsanitize. Incidentally this would also at least partially mitigate the main weakness, as -fsanitize should expose spots where platform-neutral fallback is not as platform-neutral as it should be, wouldn't it? _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev