f88f5ef109
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>
19 lines
478 B
C++
19 lines
478 B
C++
/*
|
|
* Copyright 2018 Google Inc.
|
|
*
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
* found in the LICENSE file.
|
|
*/
|
|
|
|
#include "Fuzz.h"
|
|
#include "FuzzCommon.h"
|
|
|
|
DEF_FUZZ(RegionOp, fuzz) { // `fuzz -t api -n RegionOp`
|
|
SkRegion regionA, regionB, regionC;
|
|
FuzzNiceRegion(fuzz, ®ionA, 2000);
|
|
FuzzNiceRegion(fuzz, ®ionB, 2000);
|
|
SkRegion::Op op;
|
|
fuzz->nextRange(&op, 0, SkRegion::kLastOp);
|
|
regionC.op(regionA, regionB, op);
|
|
}
|