On 22.07.2024 15:51, Tamas K Lengyel wrote: > On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeul...@suse.com> wrote: >> >> On 22.07.2024 13:27, Tamas K Lengyel wrote: >>> This target enables integration into oss-fuzz. Changing invalid input return >>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the >>> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz >>> build. >>> >>> Signed-off-by: Tamas K Lengyel <ta...@tklengyel.com> >>> --- >>> v3: don't include libfuzzer-harness in target 'all' as it requires specific >>> cc >> >> With this, how is it going to be built at all? Only by invoking the special >> target "manually" as it seems? Which sets this up for easy bit-rotting. I >> wonder what others think here ... > > Yes, by calling make with the specific target. It's not going to > bitrot because oss-fuzz will pick up any regression on a daily basis > to this target. I assume you would be interested in receiving the > fuzzing reports so it would show as a build failure in case something > broke it.
Please forgive my lack of knowledge here, but which part of whose infrastructure would pick up stuff in a daily basis, and what fuzzing reports (I've never seen any, daily or not) are you talking about? For now it feels to me as if you're talking of what's possible down the road, not what's going to happen from the moment this patch was committed in a 2nd try. If so, the gap between both points in time may be significant, and hence my bit-rotting concern would still apply. Jan
