Skip to content
This repository has been archived by the owner on Jan 10, 2024. It is now read-only.

Fix NumElements() off-by-one #20

Merged
merged 1 commit into from
Nov 22, 2016
Merged

Conversation

danwinship
Copy link
Contributor

If f.minElements and f.maxElements aren't equal then genElementCount will never actually return f.maxElements because of an off-by-one in its use of rand.Intn.

@lavalamp
Copy link
Contributor

LGTM

@lavalamp lavalamp merged commit 44d8105 into google:master Nov 22, 2016
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this pull request Dec 3, 2016
Automatic merge from submit-queue (batch tested with PRs 38049, 37823, 38000, 36646)

Test 0-length-arrays in fuzzing tests

While hacking on #37289 I noticed that our fuzzing tests test nil slices and slices of length 1, but not slices of length 0, meaning we aren't testing that 0-length slices get treated the same as nil in all the places we expect them to (and in particular, we aren't ensuring that comparisons always use api.Semantic.DeepEqual rather than reflect.DeepEqual). (Though in fact, changing the fuzzer didn't turn up any bugs, so maybe this effectively gets tested somewhere else...)

`fuzz.New().NilChance(.5).NumElements(0, 1)` means we end up generating `nil` 50% of the time, a length 0 array 25% of the time, and a length 1 array 25% of the time... maybe it should be `fuzz.New().NilChance(.33).NumElements(0, 1)` instead?

The gofuzz rebase is to pull in google/gofuzz#20, and the other fix is just a drive-by.
@danwinship danwinship deleted the num-elements branch July 6, 2017 16:47
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants