[PATCH] D65661: [compiler-rt] Move FDP to include/fuzzer/FuzzedDataProvider.h for easier use.

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D65661#1612447 <https://reviews.llvm.org/D65661#1612447>, @Dor1s wrote:

> > the terminology here means those are 2 separate inputs, right?
>
> Yes! Can you think of a better name for that? I thought "argument" or "parameter" could work, but what if those values are used somehow else (e.g. a number of iterations) and not passed to any function explicitly, then they are not technically arguments or parameters :/ "input" sounds pretty abstract to me, but any better suggestions are totally welcome.


Aha, now it makes sense. Sub-buffers?

>> And while span would act like a light-weight view with no extra allocations,
>>  this would allocate a *separate* buffer for each of these "inputs"?
> 
> I don't see a sane way to use `span` in your example. Most likely it'll end up with two integer variable on stack, which is what FDP would do as well.
> 
> But if you interpret the buffer like `int32_t*[2]`

That's what i meant, yes.

> and pass the address to the target API, you may miss some bugs because of the way how instrumentation works. We had cases like this, when e.g. off-by-one bugs were not detected.

Yeah, that i understand first-hand (:

> Educating every fuzzer developer on that matter doesn't scale. Providing an API that solves the problem does :)

Though this wrapper won't solve all the issues, this would need to be more or less consistently
used throught all the code being fuzzed, not just on the surface in just the fuzz target.
Which means it would need to be *always* available, not just when building with clang+fuzzer,
which means it would need to be located in every project's sources.
In other words, i guess not sure how putting it in clang helps, other than creating compiler lock-in.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65661/new/

https://reviews.llvm.org/D65661