commit - 49a1e1f275125808dc5dc82b692b92f50e715708
commit + 38e2d6c75d65d770d518286e0f4abd7914719dfa
blob - 68d6b02ff1c0567b69b990bce58a3de6f2f0f351
blob + a73f8a69a7a6d1ae510bd8dffc664126750e07d3
--- Glossary.md
+++ Glossary.md
<strong><a id="Coverage" href="#Coverage">Coverage</a></strong>: Some information about the behavior of the target when it executes a given input. Coverage is usually represented as the feature set that the input has triggered in the target.
-<strong><a id="Corpus" href="#Corpus">Corpus</a></strong>: (also **test corpus**, or **fuzzing corpus**) (*plural*: corpora) A set of [test inputs](#test-input). In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.
+<strong><a id="Corpus" href="#Corpus">Corpus</a></strong>: (also **test corpus**, or **fuzzing corpus**) (*plural*: corpora) A set of [test inputs](#Test_Input). In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.
<strong><a id="Cross-pollination" href="#Cross-pollination">Cross-pollination</a></strong>: The term is taken from botany, where one plant pollinates a plant of another variety. In fuzzing, cross-pollination means using a corpus for one [fuzz target](#Fuzz_target) to expand a [corpus](#corpus) for another fuzz target. For example, if there are two libraries that process the same common data format, it is often beneficial to cross-pollinate their respective corpora.
<strong><a id="Distillation" href="#Distillation">Distillation</a></strong> (creating a distilled corpus): A process of choosing a subset of a larger corpus, such that the subset has the same coverage features as the original corpus.
-<strong><a id="Dictionary" href="#Dictionary">Dictionary</a></strong>: A file which specifies interesting tokens for a [fuzz target](#Fuzz_target). Most [fuzzing engines](#fuzzing-engine) support dictionaries, and will adjust their mutation strategies to process these tokens together.
+<strong><a id="Dictionary" href="#Dictionary">Dictionary</a></strong>: A file which specifies interesting tokens for a [fuzz target](#Fuzz_target). Most [fuzzing engines](#fuzzing_engine) support dictionaries, and will adjust their mutation strategies to process these tokens together.
### F
<strong><a id="Fuzz_Target" href="#Fuzz_Target">Fuzz Target</a></strong> (also **Target Function**, or **Fuzzing Target Function**, or **Fuzzing Entry Point**): A binary, a library, an API, or rather anything that can consume bytes for input and produce some sort of coverage data as an output. See the [libFuzzer documentation](https://llvm.org/docs/LibFuzzer.html#fuzz-target) for a more detailed explanation. A fuzz target is typically given the array of bytes by [libFuzzer](https://llvm.org/docs/LibFuzzer.html) or [AFL](http://lcamtuf.coredump.cx/afl/) for coverage guided fuzzing. Read more about good fuzzing target [here](https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md).
-<strong><a id="Fuzzer" href="#Fuzzer">Fuzzer</a></strong>: The most overloaded term and used in a variety of contexts, which makes it bad. Sometimes, "Fuzzer" is referred to a [fuzz target](#Fuzz_target), a [fuzzing engine](#fuzzing-engine), a [mutation engine](#mutation-engine), a [test generator](#test-generator) or
+<strong><a id="Fuzzer" href="#Fuzzer">Fuzzer</a></strong>: The most overloaded term and used in a variety of contexts, which makes it bad. Sometimes, "Fuzzer" is referred to a [fuzz target](#Fuzz_target), a [fuzzing engine](#fuzzing_engine), a [mutation engine](#mutation-engine), a [test generator](#test-generator) or
a [fuzzer build](#fuzzer-build).
<strong><a id="Fuzz_Input" href="#Fuzz_Input">Fuzz Input</a></strong>: A sequence of bytes that can be fed to a target. The input can be an arbitrary bag of bytes, or some structured data, e.g. serialized proto.
<strong><a id="Fuzzer_build" href="#Fuzzer_build">Fuzzer Build</a></strong>: A build that contains all the fuzz targets for a given project, which is run with a specific fuzzing engine, in a specific build mode (e.g. with enabled/disabled assertions), and optionally combined with a sanitizer. In [OSS-Fuzz](https://google.github.io/oss-fuzz/), it is also known as a [job type](https://google.github.io/oss-fuzz/reference/glossary/#job-type).
-<strong><a id="Fuzzing_Engine" href="#Fuzzing_Engine">Fuzzing Engine</a></strong>: A program that produces an infinite stream of inputs for a [fuzz target](#Fuzz_target) and orchestrates the execution. Examples: [libFuzzer](http://libfuzzer.info), [AFL](lcamtuf.coredump.cx/afl/), [honggfuzz](https://github.com/google/honggfuzz), etc. See related terms [Mutation Engine](#mutation-engine) and [Test Generator](#test-generator).
+<strong><a id="Fuzzing_Engine" href="#Fuzzing_Engine">Fuzzing Engine</a></strong>: A program that produces an infinite stream of inputs for a [fuzz target](#Fuzz_target) and orchestrates the execution. Examples: [libFuzzer](http://libfuzzer.info), [AFL](lcamtuf.coredump.cx/afl/), [honggfuzz](https://github.com/google/honggfuzz), etc. See related terms [Mutation Engine](#mutation_engine) and [Test Generator](#test_generator).
### M
<strong><a id="Reliability_of_reproduction" href="#Reliability_of_reproduction">Reliability of reproduction</a></strong>: A crash is reliably reproducible if the target program consistently crashes with the same [crash state](https://google.github.io/clusterfuzz/reference/glossary/#crash-state) for the given input.
-<strong><a id="Reproducer" href="#Reproducer">Reproducer</a></strong>: (also **Test Case**): A [test input](#test-input) that can be used to reproduce a bug when processed by a fuzz target.
+<strong><a id="Reproducer" href="#Reproducer">Reproducer</a></strong>: (also **Test Case**): A [test input](#Test_Input) that can be used to reproduce a bug when processed by a fuzz target.
### S
