[openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

>>>> 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?