Doesn't look like we need to distinguish these if we just
write them as the simple
1) load the right number of bytes
2) clamp to [min,max]
This makes enum fuzzing independent of its underlying type, and may make
it easier to see the mapping from fuzzed byte stream to
nextRange()/nextEnum() values.
Change-Id: I9f785f94f513a0087ad7151b5e7bc14ddbe9314a
Reviewed-on: https://skia-review.googlesource.com/c/171820
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Some oss-fuzz bugs (like the linked one) would not reproduce
in Skia proper due to the fact that there were subtle overloads
of the various Fuzz::next() methods in FuzzCanvas.cpp that
were pulled in in Skia proper, but not oss-fuzz.
This puts all of them in to FuzzCommon.h and makes the
matrix and rrect ones opt-in (fuzz_matrix, fuzz_rrect).
Additionally, this renames fuzz.cpp -> FuzzMain.cpp so we
can properly include Fuzz.cpp in oss-fuzz without
having two mains.
Bug: oss-fuzz:10378
Change-Id: I6cf9afb471781b9fadb689482109a1e5662358b5
Reviewed-on: https://skia-review.googlesource.com/154900
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
