Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
Ok, if the function is *useful* without the fuzzer then it makes sense to
compile it without the fuzzer.
Sold.
---
If your project is set up for it, you can reply to this email and
Github user kcc commented on the issue:
https://github.com/apache/qpid-proton/pull/95
on oss-fuzz we use adapters between e.g. AFL and LLVMFuzzerTestOneInput.
See e.g.
https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/afl/afl_driver.cpp
So, a fuzzer does not have to
Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
Assuming that any compatible fuzzer has to have the same interface
(assuming they all use LLVMFuzzerTestOneInput) then they all need to supply a
compatible definition.
It's not as if
Github user kcc commented on the issue:
https://github.com/apache/qpid-proton/pull/95
Re declaration of LLVMFuzzerTestOneInput -- libFuzzer does have a single
interface header,
FuzzerInterface.h, but we typically ask *not* to use it because we want the
fuzz targets to be 100%
Github user kcc commented on the issue:
https://github.com/apache/qpid-proton/pull/95
We use the approach with binary files in a few other repos (e.g.
https://github.com/google/boringssl/tree/master/fuzz) and it works perfect.
Note that this is not only a seed for fudzzing, but
Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
Also, in general I'm not usually happy to check in generated (especially)
binary files to a source code repository.
I understand the purpose here, but it seems messy to me.
---
If
Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
In general though it's more important to get this into the repo so it can
be used going forward and then maybe it can be tidied up later.
---
If your project is set up for it, you can reply
Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
I'd be happy with just hex files, but the binary files are virtually
impossible to use sensibly without extra tools as a developer.
It might be a bit better with the fuzzing code
Github user jdanekrh commented on the issue:
https://github.com/apache/qpid-proton/pull/95
I forgot to comment about hex files.
Sure, but then there would have to be a conversion step to hex when adding
file to corpus and a conversion step from hex to binary before starting
Github user jdanekrh commented on the issue:
https://github.com/apache/qpid-proton/pull/95
I am not fan of storing binary data either, but I think it is not
unreasonable given the circumstances.
The corpus was generated automatically by the fuzzer. There is a greedy
Github user astitcher commented on the issue:
https://github.com/apache/qpid-proton/pull/95
I really like the idea of putting fuzzing tests into the source tree
(guarded appropriately by cmake tests).
I'm not very keen about putting binary only files into the corpus. Could we
11 matches
Mail list logo
