Hi Mark,
> But that doesn't really work if you use clang.
It kind of does because almost everybody who builds their projects with clang
sanitizers
turns off `z,defs` and `--no-undefined`. I agree it looks weird (and it's
probably weird) but
it's just how it has been done for I don't know how many years. My
understanding is
that it will never be fixed mostly because unlike gcc, clang doesn't support
"shared" ASan/UBSan/MSan
(or, more precisely it isn't actively maintained there and it isn't used in
general).
> sanitizer flags that aren't tested in the upstream project is a good
> idea.
>
I wouldn't say that they are arbitrary. They have been tested with about 400
projects I think
and new flags are rolled out only if they don't break anything.
> It requires a github and a google account and it hides the
> results from the upstream project.
I don't think github accounts are required there but to due to some limitations
gmail accounts
have to be used unfortunately. There is a flag there I can flip to prevent
OSS-Fuzz from
restricting bug reports in the first place but I think I wrote it elsewhere
already (after this email was sent)
and it'd probably make sense to keep discussing it there.
> Also the way they setup the fuzzers
> feels odd (like how they try to cram everything through the CFLAGS and
> how they try to link against a C++ library even for plain C projects).
They have to support a lot of different build systems there and I think it was
decided that
CFLAGS is the only thing that they can use to affect them (which I think makes
sense).
clang++ and stlibc++ have something to do with UBSan as far as I know.
> I really would like to have any fuzzing targets be part of the upstream
> project so we can all run the fuzzers instead of having to rely of
> Google.
I'm planning to move the fuzz targets upstream eventually and include them in
the test suite
at least but I think they should be
compatible with OSS-Fuzz either way (because it's kind of hard to set up
continuous
fuzzing manually)
>> I agree that it would be great to make `--enable-sanitize-
>> {undefined,address}` work with clang as well but I think it can be
>> done later on top of `--disable-undefined`.
>
> I think it should be done as part of --enable-sanitize-address.
If --enable-sanitize-address controlled it, I'm not sure how I would build
elfutils with Memory Sanitizer
(where I have to turn z,defs and no-undefined as well).
> But those seem to report bogus issues. At least in these cases, it
> seems the code is fine.
The rationale behind those checks (and why they are enabled by default) can be
found
at https://reviews.llvm.org/D67122. My understanding is that code with that
kind of UB
is known to be miscompiled from time to time.
Thanks,
Evgeny Vereshchagin
