On Tue, Aug 27, 2024 at 12:08:27PM +0300, Rayhan Faizel wrote:
On Tue, Aug 27, 2024 at 11:07 AM Martin Kletzander
<mkletzan(a)redhat.com> wrote:
>
> That was unfortunate, but since Rayhan had the first implementation done
> in a very short time we rather spent the rest of the time enhancing the
> fuzzing and it definitely bore fruit -- some of the found things are
> fixed, some are still waiting for a patch or two.
>
> The crucial part of this is the existing libprotobuf-mutator which is
> already in C++ and does provide very specific C++ APIs.
>
> Another approach (except writing our own mutator) would be to keep the
> code in a separate repository. I'm not completely sure whether we would
> still need the code modifications, I don't remember our discussions
> about whether the fuzzing compilation could work with all current
> libvirt code compiled as C and only the fuzzing parts compiled in C++.
>
All the existing code is indeed still compiled as C. Only the fuzzing
executables (under tests/fuzz/) are compiled in C++ and linked to
those C objects. We still do need some of the minor code modifications
(in PATCH 1) because existing C headers are sometimes interpreted a
bit differently from the fuzzer's PoV, even with C linkage.
Sorry, what I meant is whether it would be possible to keep the code as
is, the keyword parameters are a bit of a problem, but writing a layer
of C code to call it through from the C++ code feels weird. Of course
attributes are also complicated to make work, but those changes in the C
code are pretty okay I think.
There are still some other code modifications in tests/ and src/ for
a
few other fuzzers (mostly hotplug and CH) to make fuzzing easier.
I agree that we could keep it as a separate repo, perhaps a
subproject. I have seen some projects keep their fuzzing code separate
(mostly on oss-fuzz).
--
Rayhan Faizel