From c9144dca3d9a86827a7f88d5285b03e0bfdc5648 Mon Sep 17 00:00:00 2001 From: Kareem Khazem Date: Wed, 5 Jul 2017 08:37:57 +0100 Subject: [PATCH] [docs 1/5] Port existing HTML manual to doxygen * The existing HTML documentation under doc/html-manual has been converted to Markdown. This was done automatically using Pandoc, plus some manual work to give identifiers to sections and changing internal links to point to those sections with \ref. * The Doxygen front page now contains some content: a link to the doxygen-ated HTML manual, and a note about the API documentation. The intention here is that the entire Doxygen site could be hosted publicly, serving both users of and contributors to CBMC from a single site. * The doxyfile is updated to enable these changes. --- doc/CPPLINT.cfg | 1 + doc/architectural/front-page.md | 24 + doc/{html-manual => assets}/binsearch.c | 0 doc/{html-manual => assets}/c_to_ir.svg | 0 doc/{html-manual => assets}/cegar-1.png | Bin doc/{html-manual => assets}/counter.c | 0 .../boop-example => assets}/driver.c | 0 .../boop-example => assets}/driver.h | 0 doc/{html-manual => assets}/expr.c | 0 doc/{html-manual => assets}/expr.svg | 0 doc/{html-manual => assets}/file1.c | 0 doc/{html-manual => assets}/file2.c | 0 doc/{html-manual => assets}/gcc-wrap.c | 0 doc/{html-manual => assets}/goto_program.svg | 0 doc/{html-manual => assets}/ireptree.svg | 0 .../boop-example => assets}/kdev_t.h | 0 .../lock-example-fixed.c | 0 doc/{html-manual => assets}/lock-example.c | 0 .../boop-example => assets}/modules.h | 0 doc/{html-manual => assets}/pid.c | 0 doc/{html-manual => assets}/pid.png | Bin doc/{html-manual => assets}/refinement.png | Bin doc/{html-manual => assets}/ring_buffer1.c | 0 doc/{html-manual => assets}/ring_buffer2.c | 0 .../boop-example => assets}/spec.c | 0 doc/{html-manual => assets}/states.png | Bin doc/cprover-manual.md | 2982 +++++++++++++++++ doc/html-manual/api.shtml | 323 -- doc/html-manual/architecture.shtml | 93 - doc/html-manual/cbmc-loops.shtml | 233 -- doc/html-manual/cbmc.shtml | 377 --- doc/html-manual/counter.v | 10 - doc/html-manual/cover.shtml | 276 -- doc/html-manual/cprover-source.shtml | 877 ----- doc/html-manual/footer.inc | 5 - doc/html-manual/goto-cc-apache.shtml | 69 - doc/html-manual/goto-cc-linux.shtml | 97 - doc/html-manual/goto-cc-rockbox.shtml | 83 - doc/html-manual/goto-cc-variants.shtml | 48 - doc/html-manual/goto-cc-visual-studio.shtml | 57 - doc/html-manual/goto-cc.shtml | 144 - doc/html-manual/header.inc | 23 - doc/html-manual/highlight/CHANGES.md | 1610 --------- doc/html-manual/highlight/LICENSE | 24 - doc/html-manual/highlight/README.md | 150 - doc/html-manual/highlight/README.ru.md | 142 - doc/html-manual/highlight/highlight.pack.js | 2 - doc/html-manual/highlight/styles/agate.css | 108 - .../highlight/styles/androidstudio.css | 66 - .../highlight/styles/arduino-light.css | 88 - doc/html-manual/highlight/styles/arta.css | 73 - doc/html-manual/highlight/styles/ascetic.css | 45 - .../highlight/styles/atelier-cave-dark.css | 83 - .../highlight/styles/atelier-cave-light.css | 85 - .../highlight/styles/atelier-dune-dark.css | 69 - .../highlight/styles/atelier-dune-light.css | 69 - .../highlight/styles/atelier-estuary-dark.css | 84 - .../styles/atelier-estuary-light.css | 84 - .../highlight/styles/atelier-forest-dark.css | 69 - .../highlight/styles/atelier-forest-light.css | 69 - .../highlight/styles/atelier-heath-dark.css | 69 - .../highlight/styles/atelier-heath-light.css | 69 - .../styles/atelier-lakeside-dark.css | 69 - .../styles/atelier-lakeside-light.css | 69 - .../highlight/styles/atelier-plateau-dark.css | 84 - .../styles/atelier-plateau-light.css | 84 - .../highlight/styles/atelier-savanna-dark.css | 84 - .../styles/atelier-savanna-light.css | 84 - .../highlight/styles/atelier-seaside-dark.css | 69 - .../styles/atelier-seaside-light.css | 69 - .../styles/atelier-sulphurpool-dark.css | 69 - .../styles/atelier-sulphurpool-light.css | 69 - .../highlight/styles/brown-paper.css | 64 - .../highlight/styles/brown-papersq.png | Bin 18198 -> 0 bytes .../highlight/styles/codepen-embed.css | 60 - .../highlight/styles/color-brewer.css | 71 - doc/html-manual/highlight/styles/dark.css | 63 - doc/html-manual/highlight/styles/darkula.css | 6 - doc/html-manual/highlight/styles/default.css | 99 - doc/html-manual/highlight/styles/docco.css | 97 - doc/html-manual/highlight/styles/dracula.css | 76 - doc/html-manual/highlight/styles/far.css | 71 - .../highlight/styles/foundation.css | 88 - .../highlight/styles/github-gist.css | 71 - doc/html-manual/highlight/styles/github.css | 99 - .../highlight/styles/googlecode.css | 89 - .../highlight/styles/grayscale.css | 101 - .../highlight/styles/gruvbox-dark.css | 108 - .../highlight/styles/gruvbox-light.css | 108 - .../highlight/styles/hopscotch.css | 83 - doc/html-manual/highlight/styles/hybrid.css | 102 - doc/html-manual/highlight/styles/idea.css | 97 - doc/html-manual/highlight/styles/ir-black.css | 73 - .../highlight/styles/kimbie.dark.css | 74 - .../highlight/styles/kimbie.light.css | 74 - doc/html-manual/highlight/styles/magula.css | 70 - .../highlight/styles/mono-blue.css | 59 - .../highlight/styles/monokai-sublime.css | 83 - doc/html-manual/highlight/styles/monokai.css | 70 - doc/html-manual/highlight/styles/obsidian.css | 88 - .../highlight/styles/paraiso-dark.css | 72 - .../highlight/styles/paraiso-light.css | 72 - doc/html-manual/highlight/styles/pojoaque.css | 83 - doc/html-manual/highlight/styles/pojoaque.jpg | Bin 1186 -> 0 bytes .../highlight/styles/purebasic.css | 96 - .../highlight/styles/qtcreator_dark.css | 83 - .../highlight/styles/qtcreator_light.css | 83 - .../highlight/styles/railscasts.css | 106 - doc/html-manual/highlight/styles/rainbow.css | 85 - .../highlight/styles/school-book.css | 72 - .../highlight/styles/school-book.png | Bin 486 -> 0 bytes .../highlight/styles/solarized-dark.css | 84 - .../highlight/styles/solarized-light.css | 84 - doc/html-manual/highlight/styles/sunburst.css | 102 - .../highlight/styles/tomorrow-night-blue.css | 75 - .../styles/tomorrow-night-bright.css | 74 - .../styles/tomorrow-night-eighties.css | 74 - .../highlight/styles/tomorrow-night.css | 75 - doc/html-manual/highlight/styles/tomorrow.css | 72 - doc/html-manual/highlight/styles/vs.css | 68 - doc/html-manual/highlight/styles/xcode.css | 93 - doc/html-manual/highlight/styles/xt256.css | 92 - doc/html-manual/highlight/styles/zenburn.css | 80 - doc/html-manual/hwsw-inputs.shtml | 106 - doc/html-manual/hwsw-mapping.shtml | 131 - doc/html-manual/hwsw-tutorial.shtml | 220 -- doc/html-manual/hwsw.shtml | 116 - doc/html-manual/index.shtml | 62 - doc/html-manual/installation-cbmc.shtml | 80 - doc/html-manual/installation-plugin.shtml | 42 - doc/html-manual/installation-satabs.shtml | 139 - doc/html-manual/introduction.shtml | 162 - doc/html-manual/libraries.shtml | 54 - doc/html-manual/modeling-assertions.shtml | 152 - doc/html-manual/modeling-floating-point.shtml | 140 - doc/html-manual/modeling-nondet.shtml | 65 - doc/html-manual/modeling-pointers.shtml | 108 - doc/html-manual/pid_test_suites.xml | 500 --- doc/html-manual/properties.shtml | 208 -- doc/html-manual/satabs-aeon.shtml | 266 -- doc/html-manual/satabs-background.shtml | 152 - doc/html-manual/satabs-driver.shtml | 264 -- doc/html-manual/satabs-tutorials.shtml | 25 - doc/html-manual/satabs.shtml | 178 - src/doxyfile | 11 +- 145 files changed, 3013 insertions(+), 13567 deletions(-) create mode 100644 doc/CPPLINT.cfg create mode 100644 doc/architectural/front-page.md rename doc/{html-manual => assets}/binsearch.c (100%) rename doc/{html-manual => assets}/c_to_ir.svg (100%) rename doc/{html-manual => assets}/cegar-1.png (100%) rename doc/{html-manual => assets}/counter.c (100%) rename doc/{html-manual/boop-example => assets}/driver.c (100%) rename doc/{html-manual/boop-example => assets}/driver.h (100%) rename doc/{html-manual => assets}/expr.c (100%) rename doc/{html-manual => assets}/expr.svg (100%) rename doc/{html-manual => assets}/file1.c (100%) rename doc/{html-manual => assets}/file2.c (100%) rename doc/{html-manual => assets}/gcc-wrap.c (100%) rename doc/{html-manual => assets}/goto_program.svg (100%) rename doc/{html-manual => assets}/ireptree.svg (100%) rename doc/{html-manual/boop-example => assets}/kdev_t.h (100%) rename doc/{html-manual => assets}/lock-example-fixed.c (100%) rename doc/{html-manual => assets}/lock-example.c (100%) rename doc/{html-manual/boop-example => assets}/modules.h (100%) rename doc/{html-manual => assets}/pid.c (100%) rename doc/{html-manual => assets}/pid.png (100%) rename doc/{html-manual => assets}/refinement.png (100%) rename doc/{html-manual => assets}/ring_buffer1.c (100%) rename doc/{html-manual => assets}/ring_buffer2.c (100%) rename doc/{html-manual/boop-example => assets}/spec.c (100%) rename doc/{html-manual => assets}/states.png (100%) create mode 100644 doc/cprover-manual.md delete mode 100644 doc/html-manual/api.shtml delete mode 100644 doc/html-manual/architecture.shtml delete mode 100644 doc/html-manual/cbmc-loops.shtml delete mode 100644 doc/html-manual/cbmc.shtml delete mode 100644 doc/html-manual/counter.v delete mode 100644 doc/html-manual/cover.shtml delete mode 100644 doc/html-manual/cprover-source.shtml delete mode 100644 doc/html-manual/footer.inc delete mode 100644 doc/html-manual/goto-cc-apache.shtml delete mode 100644 doc/html-manual/goto-cc-linux.shtml delete mode 100644 doc/html-manual/goto-cc-rockbox.shtml delete mode 100644 doc/html-manual/goto-cc-variants.shtml delete mode 100644 doc/html-manual/goto-cc-visual-studio.shtml delete mode 100644 doc/html-manual/goto-cc.shtml delete mode 100644 doc/html-manual/header.inc delete mode 100644 doc/html-manual/highlight/CHANGES.md delete mode 100644 doc/html-manual/highlight/LICENSE delete mode 100644 doc/html-manual/highlight/README.md delete mode 100644 doc/html-manual/highlight/README.ru.md delete mode 100644 doc/html-manual/highlight/highlight.pack.js delete mode 100644 doc/html-manual/highlight/styles/agate.css delete mode 100644 doc/html-manual/highlight/styles/androidstudio.css delete mode 100644 doc/html-manual/highlight/styles/arduino-light.css delete mode 100644 doc/html-manual/highlight/styles/arta.css delete mode 100644 doc/html-manual/highlight/styles/ascetic.css delete mode 100644 doc/html-manual/highlight/styles/atelier-cave-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-cave-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-dune-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-dune-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-estuary-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-estuary-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-forest-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-forest-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-heath-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-heath-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-lakeside-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-lakeside-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-plateau-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-plateau-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-savanna-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-savanna-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-seaside-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-seaside-light.css delete mode 100644 doc/html-manual/highlight/styles/atelier-sulphurpool-dark.css delete mode 100644 doc/html-manual/highlight/styles/atelier-sulphurpool-light.css delete mode 100644 doc/html-manual/highlight/styles/brown-paper.css delete mode 100644 doc/html-manual/highlight/styles/brown-papersq.png delete mode 100644 doc/html-manual/highlight/styles/codepen-embed.css delete mode 100644 doc/html-manual/highlight/styles/color-brewer.css delete mode 100644 doc/html-manual/highlight/styles/dark.css delete mode 100644 doc/html-manual/highlight/styles/darkula.css delete mode 100644 doc/html-manual/highlight/styles/default.css delete mode 100644 doc/html-manual/highlight/styles/docco.css delete mode 100644 doc/html-manual/highlight/styles/dracula.css delete mode 100644 doc/html-manual/highlight/styles/far.css delete mode 100644 doc/html-manual/highlight/styles/foundation.css delete mode 100644 doc/html-manual/highlight/styles/github-gist.css delete mode 100644 doc/html-manual/highlight/styles/github.css delete mode 100644 doc/html-manual/highlight/styles/googlecode.css delete mode 100644 doc/html-manual/highlight/styles/grayscale.css delete mode 100644 doc/html-manual/highlight/styles/gruvbox-dark.css delete mode 100644 doc/html-manual/highlight/styles/gruvbox-light.css delete mode 100644 doc/html-manual/highlight/styles/hopscotch.css delete mode 100644 doc/html-manual/highlight/styles/hybrid.css delete mode 100644 doc/html-manual/highlight/styles/idea.css delete mode 100644 doc/html-manual/highlight/styles/ir-black.css delete mode 100644 doc/html-manual/highlight/styles/kimbie.dark.css delete mode 100644 doc/html-manual/highlight/styles/kimbie.light.css delete mode 100644 doc/html-manual/highlight/styles/magula.css delete mode 100644 doc/html-manual/highlight/styles/mono-blue.css delete mode 100644 doc/html-manual/highlight/styles/monokai-sublime.css delete mode 100644 doc/html-manual/highlight/styles/monokai.css delete mode 100644 doc/html-manual/highlight/styles/obsidian.css delete mode 100644 doc/html-manual/highlight/styles/paraiso-dark.css delete mode 100644 doc/html-manual/highlight/styles/paraiso-light.css delete mode 100644 doc/html-manual/highlight/styles/pojoaque.css delete mode 100644 doc/html-manual/highlight/styles/pojoaque.jpg delete mode 100644 doc/html-manual/highlight/styles/purebasic.css delete mode 100644 doc/html-manual/highlight/styles/qtcreator_dark.css delete mode 100644 doc/html-manual/highlight/styles/qtcreator_light.css delete mode 100644 doc/html-manual/highlight/styles/railscasts.css delete mode 100644 doc/html-manual/highlight/styles/rainbow.css delete mode 100644 doc/html-manual/highlight/styles/school-book.css delete mode 100644 doc/html-manual/highlight/styles/school-book.png delete mode 100644 doc/html-manual/highlight/styles/solarized-dark.css delete mode 100644 doc/html-manual/highlight/styles/solarized-light.css delete mode 100644 doc/html-manual/highlight/styles/sunburst.css delete mode 100644 doc/html-manual/highlight/styles/tomorrow-night-blue.css delete mode 100644 doc/html-manual/highlight/styles/tomorrow-night-bright.css delete mode 100644 doc/html-manual/highlight/styles/tomorrow-night-eighties.css delete mode 100644 doc/html-manual/highlight/styles/tomorrow-night.css delete mode 100644 doc/html-manual/highlight/styles/tomorrow.css delete mode 100644 doc/html-manual/highlight/styles/vs.css delete mode 100644 doc/html-manual/highlight/styles/xcode.css delete mode 100644 doc/html-manual/highlight/styles/xt256.css delete mode 100644 doc/html-manual/highlight/styles/zenburn.css delete mode 100644 doc/html-manual/hwsw-inputs.shtml delete mode 100644 doc/html-manual/hwsw-mapping.shtml delete mode 100644 doc/html-manual/hwsw-tutorial.shtml delete mode 100644 doc/html-manual/hwsw.shtml delete mode 100644 doc/html-manual/index.shtml delete mode 100644 doc/html-manual/installation-cbmc.shtml delete mode 100644 doc/html-manual/installation-plugin.shtml delete mode 100644 doc/html-manual/installation-satabs.shtml delete mode 100644 doc/html-manual/introduction.shtml delete mode 100644 doc/html-manual/libraries.shtml delete mode 100644 doc/html-manual/modeling-assertions.shtml delete mode 100644 doc/html-manual/modeling-floating-point.shtml delete mode 100644 doc/html-manual/modeling-nondet.shtml delete mode 100644 doc/html-manual/modeling-pointers.shtml delete mode 100644 doc/html-manual/pid_test_suites.xml delete mode 100644 doc/html-manual/properties.shtml delete mode 100644 doc/html-manual/satabs-aeon.shtml delete mode 100644 doc/html-manual/satabs-background.shtml delete mode 100644 doc/html-manual/satabs-driver.shtml delete mode 100644 doc/html-manual/satabs-tutorials.shtml delete mode 100644 doc/html-manual/satabs.shtml diff --git a/doc/CPPLINT.cfg b/doc/CPPLINT.cfg new file mode 100644 index 0000000000..51ff339c18 --- /dev/null +++ b/doc/CPPLINT.cfg @@ -0,0 +1 @@ +exclude_files=.* diff --git a/doc/architectural/front-page.md b/doc/architectural/front-page.md new file mode 100644 index 0000000000..4a75c82bbb --- /dev/null +++ b/doc/architectural/front-page.md @@ -0,0 +1,24 @@ +CProver Documentation +===================== + +These pages contain both user tutorials and automatically-generated API +documentation. Users can download CProver tools from the +CProver website; contributors +should use the repository +hosted on GitHub. + +### For users: + +* The \ref cprover-manual "CProver Manual" details the capabilities of + CBMC and SATABS and describes how to install and use these tools. It + also covers the underlying theory and prerequisite concepts behind how + these tools work. + +### For contributors: + +* If you already know exactly what you're looking for, the API reference + is generated from the codebase. You can search for classes and class + members in the search bar at top-right or use one of the links in the + sidebar. + +\defgroup module_hidden _hidden diff --git a/doc/html-manual/binsearch.c b/doc/assets/binsearch.c similarity index 100% rename from doc/html-manual/binsearch.c rename to doc/assets/binsearch.c diff --git a/doc/html-manual/c_to_ir.svg b/doc/assets/c_to_ir.svg similarity index 100% rename from doc/html-manual/c_to_ir.svg rename to doc/assets/c_to_ir.svg diff --git a/doc/html-manual/cegar-1.png b/doc/assets/cegar-1.png similarity index 100% rename from doc/html-manual/cegar-1.png rename to doc/assets/cegar-1.png diff --git a/doc/html-manual/counter.c b/doc/assets/counter.c similarity index 100% rename from doc/html-manual/counter.c rename to doc/assets/counter.c diff --git a/doc/html-manual/boop-example/driver.c b/doc/assets/driver.c similarity index 100% rename from doc/html-manual/boop-example/driver.c rename to doc/assets/driver.c diff --git a/doc/html-manual/boop-example/driver.h b/doc/assets/driver.h similarity index 100% rename from doc/html-manual/boop-example/driver.h rename to doc/assets/driver.h diff --git a/doc/html-manual/expr.c b/doc/assets/expr.c similarity index 100% rename from doc/html-manual/expr.c rename to doc/assets/expr.c diff --git a/doc/html-manual/expr.svg b/doc/assets/expr.svg similarity index 100% rename from doc/html-manual/expr.svg rename to doc/assets/expr.svg diff --git a/doc/html-manual/file1.c b/doc/assets/file1.c similarity index 100% rename from doc/html-manual/file1.c rename to doc/assets/file1.c diff --git a/doc/html-manual/file2.c b/doc/assets/file2.c similarity index 100% rename from doc/html-manual/file2.c rename to doc/assets/file2.c diff --git a/doc/html-manual/gcc-wrap.c b/doc/assets/gcc-wrap.c similarity index 100% rename from doc/html-manual/gcc-wrap.c rename to doc/assets/gcc-wrap.c diff --git a/doc/html-manual/goto_program.svg b/doc/assets/goto_program.svg similarity index 100% rename from doc/html-manual/goto_program.svg rename to doc/assets/goto_program.svg diff --git a/doc/html-manual/ireptree.svg b/doc/assets/ireptree.svg similarity index 100% rename from doc/html-manual/ireptree.svg rename to doc/assets/ireptree.svg diff --git a/doc/html-manual/boop-example/kdev_t.h b/doc/assets/kdev_t.h similarity index 100% rename from doc/html-manual/boop-example/kdev_t.h rename to doc/assets/kdev_t.h diff --git a/doc/html-manual/lock-example-fixed.c b/doc/assets/lock-example-fixed.c similarity index 100% rename from doc/html-manual/lock-example-fixed.c rename to doc/assets/lock-example-fixed.c diff --git a/doc/html-manual/lock-example.c b/doc/assets/lock-example.c similarity index 100% rename from doc/html-manual/lock-example.c rename to doc/assets/lock-example.c diff --git a/doc/html-manual/boop-example/modules.h b/doc/assets/modules.h similarity index 100% rename from doc/html-manual/boop-example/modules.h rename to doc/assets/modules.h diff --git a/doc/html-manual/pid.c b/doc/assets/pid.c similarity index 100% rename from doc/html-manual/pid.c rename to doc/assets/pid.c diff --git a/doc/html-manual/pid.png b/doc/assets/pid.png similarity index 100% rename from doc/html-manual/pid.png rename to doc/assets/pid.png diff --git a/doc/html-manual/refinement.png b/doc/assets/refinement.png similarity index 100% rename from doc/html-manual/refinement.png rename to doc/assets/refinement.png diff --git a/doc/html-manual/ring_buffer1.c b/doc/assets/ring_buffer1.c similarity index 100% rename from doc/html-manual/ring_buffer1.c rename to doc/assets/ring_buffer1.c diff --git a/doc/html-manual/ring_buffer2.c b/doc/assets/ring_buffer2.c similarity index 100% rename from doc/html-manual/ring_buffer2.c rename to doc/assets/ring_buffer2.c diff --git a/doc/html-manual/boop-example/spec.c b/doc/assets/spec.c similarity index 100% rename from doc/html-manual/boop-example/spec.c rename to doc/assets/spec.c diff --git a/doc/html-manual/states.png b/doc/assets/states.png similarity index 100% rename from doc/html-manual/states.png rename to doc/assets/states.png diff --git a/doc/cprover-manual.md b/doc/cprover-manual.md new file mode 100644 index 0000000000..90d609193d --- /dev/null +++ b/doc/cprover-manual.md @@ -0,0 +1,2982 @@ +\ingroup module_hidden +\page cprover-manual CProver User Manual + +\author Daniel Kroening + +This tutorial is intended for users of CProver (CBMC, SatAbs, and +associated tools). + +\tableofcontents + +\section man_introduction Introduction + +## Motivation + +Numerous tools to hunt down functional design flaws in silicon have been +available for many years, mainly due to the enormous cost of hardware +bugs. The use of such tools is wide-spread. In contrast, the market for +tools that address the need for quality software is still in its +infancy. + +Research in software quality has an enormous breadth. We focus the +presentation using two criteria: + +1. We believe that any form of quality requires a specific *guarantee*, + in theory and practice. +2. The sheer size of software designs requires techniques that are + highly *automated*. + +In practice, quality guarantees usually do not refer to "total +correctness" of a design, as ensuring the absence of all bugs is too +expensive for most applications. In contrast, a guarantee of the absence +of specific flaws is achievable, and is a good metric of quality. + +We document two programs that try to achieve formal guarantees of the +absence of specific problems: CBMC and SATABS. The algorithms +implemented by CBMC and SATABS are complementary, and often, one tool is +able to solve a problem that the other cannot solve. + +Both CBMC and SATABS are verification tools for ANSI-C/C++ programs. +They verify array bounds (buffer overflows), pointer safety, exceptions +and user-specified assertions. Both tools model integer arithmetic +accurately, and are able to reason about machine-level artifacts such as +integer overflow. CBMC and SATABS are therefore able to detect a class +of bugs that has so far gone unnoticed by many other verification tools. +This manual also covers some variants of CBMC, which includes HW-CBMC +for +\ref man_hard-soft-introduction "hardware/software co-verification". + +## Bounded Model Checking with CBMC + +CBMC implements a technique called *Bounded Model Checking* (BMC). In +BMC, the transition relation for a complex state machine and its +specification are jointly unwound to obtain a Boolean formula, which is +then checked for satisfiability by using an efficient SAT procedure. If +the formula is satisfiable, a counterexample is extracted from the +output of the SAT procedure. If the formula is not satisfiable, the +program can be unwound more to determine if a longer counterexample +exists. + +In many engineering domains, real-time guarantees are a strict +requirement. An example is software embedded in automotive controllers. +As a consequence, the loop constructs in these types of programs often +have a strict bound on the number of iterations. CBMC is able to +formally verify such bounds by means of *unwinding assertions*. Once +this bound is established, CBMC is able to prove the absence of errors. + +A more detailed description of how to apply CBMC to verify programs is +\ref man_cbmc-tutorial "here". + +## Automatic Program Verification with SATABS + +In many cases, lightweight properties such as array bounds do not rely +on the entire program. A large fraction of the program is *irrelevant* +to the property. SATABS exploits this observation and computes an +*abstraction* of the program in order to handle large amounts of code. + +In order to use SATABS it is not necessary to understand the abstraction +refinement process. For the interested reader, a high-level introduction +to abstraction refinement is provided +\ref man_satabs-overview "here". +We also provide +\ref man_satabs-tutorials "tutorials on how to use SATABS". + +Just as CBMC, SATABS attempts to build counterexamples that refute the +property. If such a counterexample is found, it is presented to the +engineer to facilitate localization and repair of the program. + +### Example: Buffer Overflows + +In order to give a brief overview of the capabilities of CBMC and SATABS +we start with a small example. The issue of *[buffer +overflows](http://en.wikipedia.org/wiki/Buffer_overflow)* has obtained +wide public attention. A buffer is a contiguously-allocated chunk of +memory, represented by an array or a pointer in C. Programs written in C +do not provide automatic bounds checking on the buffer, which means a +program can – accidentally or maliciously – write past a buffer. The +following example is a perfectly valid C program (in the sense that a +compiler compiles it without any errors): + +```{.c} +int main() +{ + int buffer[10]; + buffer[20] = 10; +} +``` + +However, the write access to an address outside the allocated memory +region can lead to unexpected behavior. In particular, such bugs can be +exploited to overwrite the return address of a function, thus enabling +the execution of arbitrary user-induced code. CBMC and SATABS are able +to detect this problem and reports that the "upper bound property" of +the buffer is violated. CBMC and SATABS are capable of checking these +lower and upper bounds, even for arrays with dynamic size. A detailed +discussion of the properties that CBMC and SATABS can check +automatically is \ref man_instrumentation-properties "here". + +## Hardware/Software Co-Verification + +Software programs often interact with hardware in a non-trivial manner, +and many properties of the overall design only arise from the interplay +of both components. CBMC and SATABS therefore support *Co-Verification*, +i.e., are able to reason about a C/C++ program together with a circuit +description given in Verilog. + +These co-verification capabilities can also be applied to perform +refinement proofs. Software programs are often used as high-level +descriptions of circuitry. While both describe the same functionality, +the hardware implementation usually contains more detail. It is highly +desirable to establish some form for equivalence between the two +descriptions. Hardware/Software co-verification and equivalence checking +with CBMC and SATABS are described +\ref man_hard-soft-introduction "here". + + +\section man_installation Installation + +\subsection man_install-cbmc Installing CBMC + +### Requirements + +CBMC is available for Windows, i86 Linux, and MacOS X. CBMC requires a +code pre-processing environment comprising of a suitable preprocessor +and an a set of header files. + +1. **Linux:** the preprocessor and the header files typically come with + a package called *gcc*, which must be installed prior to the + installation of CBMC. + +2. **Windows:** The Windows version of CBMC requires the preprocessor + `cl.exe`, which is part of Microsoft Visual Studio. We recommend the + free [Visual Studio Community + 2013](http://www.visualstudio.com/en-us/products/visual-studio-community-vs). + +3. **MacOS:** Install the [XCode Command Line + Utilities](http://developer.apple.com/technologies/xcode.html) prior + to installing CBMC. Just installing XCode alone is not enough. + +Important note for Windows users: Visual Studio's `cl.exe` relies on a +complex set of environment variables to identify the target architecture +and the directories that contain the header files. You must run CBMC +from within the *Visual Studio Command Prompt*. + +Note that the distribution files for the [Eclipse +plugin](installation-plugin.shtml) include the CBMC executable. +Therefore, if you intend to run CBMC exclusively within Eclipse, you can +skip the installation of the CBMC executable. However, you still have to +install the compiler environment as described above. + +### Installing the CBMC Binaries + +1. Download CBMC for your operating system. The binaries are available + from http://www.cprover.org/cbmc/. +2. Unzip/untar the archive into a directory of your choice. We + recommend to add this directory to your `PATH` environment variable. + +You are now ready to \ref man_cbmc-tutorial "use CBMC"! + +### Building CBMC from Source + +Alternatively, the CBMC source code is available [via +SVN](http://www.cprover.org/svn/cbmc/). To compile the source code, +follow [these +instructions](http://www.cprover.org/svn/cbmc/trunk/COMPILING). + +\subsection man_install-satabs Installing SATABS + +### Requirements + +SATABS is available for Windows, i86 Linux, and MacOS X. SATABS requires +a code pre-processing environment comprising of a suitable preprocessor +and an a set of header files. + +1. **Linux:** the preprocessor and the header files typically come with + a package called *gcc*, which must be installed prior to the + installation of SATABS. +2. **Windows:** The Windows version of SATABS requires the preprocessor + `cl.exe`, which is part of Visual Studio (including the free [Visual + Studio + Express](http://msdn.microsoft.com/vstudio/express/visualc/)). +3. **MacOS:** Install + [XCode](http://developer.apple.com/technologies/xcode.html) prior to + installing SATABS. + +Important note for Windows users: Visual Studio's `cl.exe` relies on a +complex set of environment variables to identify the target architecture +and the directories that contain the header files. You must run SATABS +from within the *Visual Studio Command Prompt*. + +Note that the distribution files for the [Eclipse +plugin](installation-plugin.shtml) include the command-line tools. +Therefore, if you intend to run SATABS exclusively within Eclipse, you +can skip the installation of the command-line tools. However, you still +have to install the compiler environment as described above. + +### Choosing and Installing a Model Checker + +You need to install a Model Checker in order to be able to run SATABS. +You can choose between following alternatives: + +- **Cadence SMV**. Available from http://www.kenmcmil.com/smv.html. + Cadence SMV is a commercial model checker. The free version that is + available on the homepage above must not be used for commercial + purposes (read the license agreement thoroughly before you download + the tool). The documentation for SMV can be found in the directory + where you unzip/untar SMV under ./smv/doc/smv/. Read the + installation instructions carefully. The Linux/MacOS versions + require setting environment variables. You must add add the + directory containing the `smv` binary (located in ./smv/bin/, + relative to the path where you unpacked it) to your `PATH` + environment variable. SATABS uses Cadence SMV by default. + +- **NuSMV**. Available from http://nusmv.irst.itc.it/. NuSMV is the + open source alternative to Cadence SMV. Installation instructions + and documentation can be found on the NuSMV homepage. The directory + containing the NuSMV binary should be added to your `PATH` + environment variable. Use the option + + --modelchecker nusmv + + to instruct SATABS to use NuSMV. + +- **BOPPO**. Available from http://www.cprover.org/boppo/. BOPPO is + a model checker that uses SAT-solving algorithms. BOPPO relies on a + built-in SAT solver and Quantor, a solver for quantified boolean + formulas that is currently bundled with BOPPO, but also available + separately from . We recommend to add + the directories containing both tools to your `PATH` environment + variable. Use the option + + --modelchecker boppo + + when you call SATABS and want it to use BOPPO instead of SMV. + +- **BOOM**. Available from http://www.cprover.org/boom/. Boom has a + number of unique features, including the verification of programs + with unbounded thread creation. + +### Installing SATABS + +1. Download SATABS for your operating system. The binaries are + available from . +2. Unzip/untar the archive into a directory of your choice. We + recommend to add this directory to your `PATH` environment variable. + +Now you can execute SATABS. Try running SATABS on the small examples +presented in the \ref man_satabs-tutorials "SATABS tutorial". If you use +the Cadence SMV model checker, the only command line arguments you have +to specify are the names of the files that contain your program. + + +\subsection man_install-eclipse Installing the Eclipse Plugin + +### Requirements + +We provide a graphical user interface to CBMC and SATABS, which is +realized as a plugin to the Eclipse framework. Eclipse is available at +http://www.eclipse.org. We do not provide installation instructions for +Eclipse (basically, you only have to download the current version and +extract the files to your hard-disk) and assume that you have already +installed the current version. + +CBMC and SATABS have their own requirements. As an example, both CBMC and SATABS require a suitable preprocessor and a set of header files. As +first step, you should therefore follow the installation instructions +for \ref man_install-cbmc "CBMC" and \ref man_install-satabs "SATABS". + +Important note for Windows users: Visual Studio's `cl.exe` relies on a +complex set of environment variables to identify the target architecture +and the directories that contain the header files. You must run Eclipse +from within the *Visual Studio Command Prompt*. + +### Installing the Eclipse Plugin + +The installation instructions for the Eclipse Plugin, including the link +to the download site, are available +[here](http://www.cprover.org/eclipse-plugin/). This includes a small +tutorial on how to use the Eclipse plugin. + + +\section man_cbmc CBMC: Bounded Model Checking for C, C++ and Java + +\subsection man_cbmc-tutorial A Short Tutorial + +### First Steps + +We assume you have already installed CBMC and the necessary support +files on your system. If not so, please follow the instructions +\ref man_install-cbmc "here". + +Like a compiler, CBMC takes the names of .c files as command line +arguments. CBMC then translates the program and merges the function +definitions from the various .c files, just like a linker. But instead +of producing a binary for execution, CBMC performs symbolic simulation +on the program. + +As an example, consider the following simple program, named file1.c: + + int puts(const char *s) { } + + int main(int argc, char **argv) { + puts(argv[2]); + } + +Of course, this program is faulty, as the `argv` array might have fewer +than three elements, and then the array access `argv[2]` is out of +bounds. Now, run CBMC as follows: + + cbmc file1.c --show-properties --bounds-check --pointer-check + +The two options `--bounds-check` and `--pointer-check` instruct CBMC to +look for errors related to pointers and array bounds. CBMC will print +the list of properties it checks. Note that it lists, among others, a +property labelled with "object bounds in argv" together with the location +of the faulty array access. As you can see, CBMC largely determines the +property it needs to check itself. This is realized by means of a +preliminary static analysis, which relies on computing a fixed point on +various [abstract +domains](http://en.wikipedia.org/wiki/Abstract_interpretation). More +detail on automatically generated properties is provided +\ref man_instrumentation-properties "here". + +Note that these automatically generated properties need not necessarily +correspond to bugs – these are just *potential* flaws, as abstract +interpretation might be imprecise. Whether these properties hold or +correspond to actual bugs needs to be determined by further analysis. + +CBMC performs this analysis using *symbolic simulation*, which +corresponds to a translation of the program into a formula. The formula +is then combined with the property. Let's look at the formula that is +generated by CBMC's symbolic simulation: + + cbmc file1.c --show-vcc --bounds-check --pointer-check + +With this option, CBMC performs the symbolic simulation and prints the +verification conditions on the screen. A verification condition needs to +be proven to be valid by a [decision +procedure](http://en.wikipedia.org/wiki/Decision_problem) in order to +assert that the corresponding property holds. Let's run the decision +procedure: + + cbmc file1.c --bounds-check --pointer-check + +CBMC transforms the equation you have seen before into CNF and passes it +to a SAT solver (more background on this step is in the book on +[Decision Procedures](http://www.decision-procedures.org/)). It then +determines which of the properties that it has generated for the program +hold and which do not. Using the SAT solver, CBMC detects that the +property for the object bounds of `argv` does not hold, and will thus +print a line as follows: + + [main.pointer_dereference.6] dereference failure: object bounds in argv[(signed long int)2]: FAILURE + +### Counterexample Traces + +Let us have a closer look at this property and why it fails. To aid the +understanding of the problem, CBMC can generate a *counterexample trace* +for failed properties. To obtain this trace, run + + cbmc file1.c --bounds-check --trace + +CBMC then prints a counterexample trace, i.e., a program trace that +begins with `main` and ends in a state which violates the property. In +our example, the program trace ends in the faulty array access. It also +gives the values the input variables must have for the bug to occur. In +this example, `argc` must be one to trigger the out-of-bounds array +access. If you add a branch to the example that requires that `argc>=3`, +the bug is fixed and CBMC will report that the proofs of all properties +have been successful. + +### Verifying Modules + +In the example above, we used a program that starts with a `main` +function. However, CBMC is aimed at embedded software, and these kinds +of programs usually have different entry points. Furthermore, CBMC is +also useful for verifying program modules. Consider the following +example, called file2.c: + + int array[10]; + int sum() { + unsigned i, sum; + + sum=0; + for(i=0; i<10; i++) + sum+=array[i]; + } + +In order to set the entry point to the `sum` function, run + + cbmc file2.c --function sum --bounds-check + +It is often necessary to build a suitable *harness* for the function in +order to set up the environment appropriately. + +### Loop Unwinding + +When running the previous example, you will have noted that CBMC unwinds +the `for` loop in the program. As CBMC performs Bounded Model Checking, +all loops have to have a finite upper run-time bound in order to +guarantee that all bugs are found. CBMC can optionally check that enough +unwinding is performed. As an example, consider the program binsearch.c: + + int binsearch(int x) { + int a[16]; + signed low=0, high=16; + + while(low>1); + + if(a[middle]x) + low=middle+1; + else // a[middle]==x + return middle; + } + + return -1; + } + +If you run CBMC on this function, you will notice that the unwinding +does not stop on its own. The built-in simplifier is not able to +determine a run time bound for this loop. The unwinding bound has to be +given as a command line argument: + + cbmc binsearch.c --function binsearch --unwind 6 --bounds-check --unwinding-assertions + +CBMC verifies that verifies the array accesses are within the bounds; +note that this actually depends on the result of the right shift. In +addition, as CBMC is given the option `--unwinding-assertions`, it also +checks that enough unwinding is done, i.e., it proves a run-time bound. +For any lower unwinding bound, there are traces that require more loop +iterations. Thus, CBMC will report that the unwinding assertion has +failed. As usual, a counterexample trace that documents this can be +obtained with the option `--property`. + +### Unbounded Loops + +CBMC can also be used for programs with unbounded loops. In this case, +CBMC is used for bug hunting only; CBMC does not attempt to find all +bugs. The following program (lock-example.c) is an example of a program +with a user-specified property: + + _Bool nondet_bool(); + _Bool LOCK = 0; + + _Bool lock() { + if(nondet_bool()) { + assert(!LOCK); + LOCK=1; + return 1; } + + return 0; + } + + void unlock() { + assert(LOCK); + LOCK=0; + } + + int main() { + unsigned got_lock = 0; + int times; + + while(times > 0) { + if(lock()) { + got_lock++; + /* critical section */ + } + + if(got_lock!=0) + unlock(); + + got_lock--; + times--; + } + } + +The `while` loop in the `main` function has no (useful) run-time bound. +Thus, a bound has to be set on the amount of unwinding that CBMC +performs. There are two ways to do so: + +1. The `--unwind` command-line parameter can to be used to limit the + number of times loops are unwound. +2. The `--depth` command-line parameter can be used to limit the number + of program steps to be processed. + +Given the option `--unwinding-assertions`, CBMC checks whether the +arugment to `--unwind` is large enough to cover all program paths. If +the argument is too small, CBMC will detect that not enough unwinding is +done reports that an unwinding assertion has failed. + +Reconsider the example. For a loop unwinding bound of one, no bug is +found. But already for a bound of two, CBMC detects a trace that +violates an assertion. Without unwinding assertions, or when using the +`--depth` command line switch, CBMC does not prove the program correct, +but it can be helpful to find program bugs. The various command line +options that CBMC offers for loop unwinding are described in the section +on \ref man_cbmc-loops "understanding loop unwinding". + +### A Note About Compilers and the ANSI-C Library + +Most C programs make use of functions provided by a library; instances +are functions from the standard ANSI-C library such as `malloc` or +`printf`. The verification of programs that use such functions has two +requirements: + +1. Appropriate header files have to be provided. These header files + contain *declarations* of the functions that are to be used. +2. Appropriate *definitions* have to be provided. + +Most C compilers come with header files for the ANSI-C library +functions. We briefly discuss how to obtain/install these library files. + +#### Linux + +Linux systems that are able to compile software are usually equipped +with the appropriate header files. Consult the documentation of your +distribution on how to install the compiler and the header files. First +try to compile some significant program before attempting to verify it. + +#### Windows + +On Microsoft Windows, CBMC is pre-configured to use the compiler that is +part of Microsoft's Visual Studio. Microsoft's [Visual Studio +Community](http://www.visualstudio.com/en-us/products/visual-studio-community-vs) +is fully featured and available for download for free from the Microsoft +webpage. Visual Studio installs the usual set of header files together +with the compiler. However, the Visual Studio compiler requires a large +set of environment variables to function correctly. It is therefore +required to run CBMC from the *Visual Studio Command Prompt*, which can +be found in the menu *Visual Studio Tools*. + +Note that in both cases, only header files are available. CBMC only +comes with a small set of definitions, which includes functions such as +`malloc`. Detailed information about the built-in definitions is +\ref man_instrumentation-libraries "here". + +### Command Line Interface + +This section describes the command line interface of CBMC. Like a C +compiler, CBMC takes the names of the .c source files as arguments. +Additional options allow to customize the behavior of CBMC. Use +`cbmc --help` to get a full list of the available options. + +Structured output can be obtained from CBMC using the option `--xml-ui`. +Any output from CBMC (e.g., counterexamples) will then use an XML +representation. + +### Further Reading + +- \ref man_cbmc-loops "Understanding Loop Unwinding" +- [Hardware Verification using ANSI-C Programs as a + Reference](http://www-2.cs.cmu.edu/~svc/papers/view-publications-ck03.html) +- [Behavioral Consistency of C and Verilog Programs Using Bounded + Model Checking](http://www-2.cs.cmu.edu/~svc/papers/view-publications-cky03.html) +- [A Tool for Checking ANSI-C + Programs](http://www-2.cs.cmu.edu/~svc/papers/view-publications-ckl2004.html) + +We also have a [list of interesting applications of +CBMC](http://www.cprover.org/cbmc/applications/). + + +\subsection man_cbmc-loops Understanding Loop Unwinding + +### Iteration-based Unwinding + +The basic idea of CBMC is to model the computation of the programs up to +a particular depth. Technically, this is achieved by a process that +essentially amounts to *unwinding loops*. This concept is best +illustrated with a generic example: + + int main(int argc, char **argv) { + while(cond) { + BODY CODE + } + } + +A BMC instance that will find bugs with up to five iterations of the +loop would contain five copies of the loop body, and essentially +corresponds to checking the following loop-free program: + + int main(int argc, char **argv) { + if(cond) { + BODY CODE COPY 1 + if(cond) { + BODY CODE COPY 2 + if(cond) { + BODY CODE COPY 3 + if(cond) { + BODY CODE COPY 4 + if(cond) { + BODY CODE COPY 5 + } + } + } + } + } + } + +Note the use of the `if` statement to prevent the execution of the loop +body in the case that the loop ends before five iterations are executed. +The construction above is meant to produce a program that is trace +equivalent with the original programs for those traces that contain up +to five iterations of the loop. + +In many cases, CBMC is able to automatically determine an upper bound on +the number of loop iterations. This may even work when the number of +loop unwindings is not constant. Consider the following example: + + _Bool f(); + + int main() { + for(int i=0; i<100; i++) { + if(f()) break; + } + assert(0); + } + +The loop in the program above has an obvious upper bound on the number +of iterations, but note that the loop may abort prematurely depending on +the value that is returned by `f()`. CBMC is nevertheless able to +automatically unwind the loop to completion. + +This automatic detection of the unwinding bound may fail if the number +of loop iterations is highly data-dependent. Furthermore, the number of +iterations that are executed by any given loop may be too large or may +simply be unbounded. For this case, CBMC offers the command-line option +`--unwind B`, where `B` denotes a number that corresponds to the maximal +number of loop unwindings CBMC performs on any loop. + +Note that the number of unwindings is measured by counting the number of +*backjumps*. In the example above, note that the condition `i<100` is in +fact evaluated 101 times before the loop terminates. Thus, the loop +requires a limit of 101, and not 100. + +### Setting Separate Unwinding Limits + +The setting given with `--unwind` is used globally, that is, for all +loops in the program. In order to set individual limits for the loops, +first use + + --show-loops + +to obtain a list of all loops in the program. Then identify the loops +you need to set a separate bound for, and note their loop ID. Then use + + --unwindset L:B,L:B,... + +where `L` denotes a loop ID and `B` denotes the bound for that loop. + +As an example, consider a program with two loops in the function main: + + --unwindset c::main.0:10,c::main.1:20 + +This sets a bound of 10 for the first loop, and a bound of 20 for the +second loop. + +What if the number of unwindings specified is too small? In this case, +bugs that require paths that are deeper may be missed. In order to +address this problem, CBMC can optionally insert checks that the given +unwinding bound is actually sufficiently large. These checks are called +*unwinding assertions*, and are enabled with the option +`--unwinding-assertions`. Continuing the generic example above, this +unwinding assertion for a bound of five corresponds to checking the +following loop-free program: + + int main(int argc, char **argv) { + if(cond) { + BODY CODE COPY 1 + if(cond) { + BODY CODE COPY 2 + if(cond) { + BODY CODE COPY 3 + if(cond) { + BODY CODE COPY 4 + if(cond) { + BODY CODE COPY 5 + assert(!cond); + } + } + } + } + } + } + +The unwinding assertions can be verified just like any other generated +assertion. If all of them are proven to hold, the given loop bounds are +sufficient for the program. This establishes a [high-level worst-case +execution time](http://en.wikipedia.org/wiki/Worst-case_execution_time) +(WCET). + +In some cases, it is desirable to cut off very deep loops in favor of +code that follows the loop. As an example, consider the following +program: + + int main() { + for(int i=0; i<10000; i++) { + BODY CODE + } + assert(0); + } + +In the example above, small values of `--unwind` will prevent that the +assertion is reached. If the code in the loop is considered irrelevant +to the later assertion, use the option + + --partial-loops + +This option will allow paths that execute loops only partially, enabling +a counterexample for the assertion above even for small unwinding +bounds. The disadvantage of using this option is that the resulting path +may be spurious, i.e., may not exist in the original program. + +### Depth-based Unwinding + +The loop-based unwinding bound is not always appropriate. In particular, +it is often difficult to control the size of the generated formula when +using the `--unwind` option. The option + + --depth nr + +specifies an unwinding bound in terms of the number of instructions that +are executed on a given path, irrespectively of the number of loop +iterations. Note that CBMC uses the number of instructions in the +control-flow graph as the criterion, not the number of instructions in +the source code. + +\subsection man_cbmc-cover COVER: Test Suite Generation with CBMC + + +### A Small Tutorial with A Case Study + +We assume that CBMC is installed on your system. If not so, follow +\ref man_install-cbmc "these instructions". + +CBMC can be used to automatically generate test cases that satisfy a +certain [code coverage](https://en.wikipedia.org/wiki/Code_coverage) +criteria. Common coverage criteria include branch coverage, condition +coverage and [Modified Condition/Decision Coverage +(MC/DC)](https://en.wikipedia.org/wiki/Modified_condition/decision_coverage). +Among others, MC/DC is required by several avionics software development +guidelines to ensure adequate testing of safety critical software. +Briefly, in order to satisfy MC/DC, for every conditional statement +containing boolean decisions, each Boolean variable should be evaluated +one time to "true" and one time to "false", in a way that affects the +outcome of the decision. + +In the following, we are going to demonstrate how to apply the test +suite generation functionality in CBMC, by means of a case study. The +following program is an excerpt from a real-time embedded benchmark +[PapaBench](https://www.irit.fr/recherches/ARCHI/MARCH/rubrique.php3?id_rubrique=97), +and implements part of a fly-by-wire autopilot for an Unmanned Aerial +Vehicle (UAV). It is adjusted mildly for our purposes. + +The aim of function `climb_pid_run` is to control the vertical climb of +the UAV. Details on the theory behind this operation are documented in +the [wiki](https://wiki.paparazziuav.org/wiki/Theory_of_Operation) for +the Paparazzi UAV project. The behaviour of this simple controller, +supposing that the desired speed is 0.5 meters per second, is plotted in +the Figure below. + +\image html pid.png "The pid controller" + + 01: // CONSTANTS: + 02: #define MAX_CLIMB_SUM_ERR 10 + 03: #define MAX_CLIMB 1 + 04: + 05: #define CLOCK 16 + 06: #define MAX_PPRZ (CLOCK*600) + 07: + 08: #define CLIMB_LEVEL_GAZ 0.31 + 09: #define CLIMB_GAZ_OF_CLIMB 0.75 + 10: #define CLIMB_PITCH_OF_VZ_PGAIN 0.05 + 11: #define CLIMB_PGAIN -0.03 + 12: #define CLIMB_IGAIN 0.1 + 13: + 14: const float pitch_of_vz_pgain=CLIMB_PITCH_OF_VZ_PGAIN; + 15: const float climb_pgain=CLIMB_PGAIN; + 16: const float climb_igain=CLIMB_IGAIN; + 17: const float nav_pitch=0; + 18: + 19: /** PID function INPUTS */ + 20: // The user input: target speed in vertical direction + 21: float desired_climb; + 22: // Vertical speed of the UAV detected by GPS sensor + 23: float estimator_z_dot; + 24: + 25: /** PID function OUTPUTS */ + 26: float desired_gaz; + 27: float desired_pitch; + 28: + 29: /** The state variable: accumulated error in the control */ + 30: float climb_sum_err=0; + 31: + 32: /** Computes desired_gaz and desired_pitch */ + 33: void climb_pid_run() + 34: { + 35: + 36: float err=estimator_z_dot-desired_climb; + 37: + 38: float fgaz=climb_pgain*(err+climb_igain*climb_sum_err)+CLIMB_LEVEL_GAZ+CLIMB_GAZ_OF_CLIMB*desired_climb; + 39: + 40: float pprz=fgaz*MAX_PPRZ; + 41: desired_gaz=((pprz>=0 && pprz<=MAX_PPRZ) ? pprz : (pprz>MAX_PPRZ ? MAX_PPRZ : 0)); + 42: + 43: /** pitch offset for climb */ + 44: float pitch_of_vz=(desired_climb>0) ? desired_climb*pitch_of_vz_pgain : 0; + 45: desired_pitch=nav_pitch+pitch_of_vz; + 46: + 47: climb_sum_err=err+climb_sum_err; + 48: if (climb_sum_err>MAX_CLIMB_SUM_ERR) climb_sum_err=MAX_CLIMB_SUM_ERR; + 49: if (climb_sum_err<-MAX_CLIMB_SUM_ERR) climb_sum_err=-MAX_CLIMB_SUM_ERR; + 50: + 51: } + 52: + 53: int main() + 54: { + 55: + 56: while(1) + 57: { + 58: /** Non-deterministic input values */ + 59: desired_climb=nondet_float(); + 60: estimator_z_dot=nondet_float(); + 61: + 62: /** Range of input values */ + 63: __CPROVER_assume(desired_climb>=-MAX_CLIMB && desired_climb<=MAX_CLIMB); + 64: __CPROVER_assume(estimator_z_dot>=-MAX_CLIMB && estimator_z_dot<=MAX_CLIMB); + 65: + 66: __CPROVER_input("desired_climb", desired_climb); + 67: __CPROVER_input("estimator_z_dot", estimator_z_dot); + 68: + 69: climb_pid_run(); + 70: + 71: __CPROVER_output("desired_gaz", desired_gaz); + 72: __CPROVER_output("desired_pitch", desired_pitch); + 73: + 74: } + 75: + 76: return 0; + 77: } + +In order to test the PID controller, we construct a main control loop, +which repeatedly invokes the function `climb_pid_run` (line 69). This +PID function has two input variables: the desired speed `desired_climb` +and the estimated speed `estimated_z_dot`. In the beginning of each loop +iteration, values of the inputs are assigned non-deterministically. +Subsequently, the `__CPROVER_assume` statement in lines 63 and 64 +guarantees that both values are bounded within a valid range. The +`__CPROVER_input` and `__CPROVER_output` will help clarify the inputs +and outputs of interest for generating test suites. + +To demonstrate the automatic test suite generation in CBMC, we call the +following command and we are going to explain the command line options +one by one. + + cbmc pid.c --cover mcdc --unwind 6 --xml-ui + +The option `--cover mcdc` specifies the code coverage criterion. There +are four conditional statements in the PID function: in line 41, line +44, line 48 and line 49. To satisfy MC/DC, the test suite has to meet +multiple requirements. For instance, each conditional statement needs to +evaluate to *true* and *false*. Consider the condition +`"pprz>=0 && pprz<=MAX_PPRZ"` in line 41. CBMC instruments three +coverage goals to control the respective evaluated results of +`"pprz>=0"` and `"pprz<=MAX_PPRZ"`. We list them in below and they +satisfy the MC/DC rules. Note that `MAX_PPRZ` is defined as 16 \* 600 in +line 06 of the program. + + !(pprz >= (float)0) && pprz <= (float)(16 * 600) id="climb_pid_run.coverage.1" + pprz >= (float)0 && !(pprz <= (float)(16 * 600)) id="climb_pid_run.coverage.2" + pprz >= (float)0 && pprz <= (float)(16 * 600) id="climb_pid_run.coverage.3" + +The "id" of each coverage goal is automatically assigned by CBMC. For +every coverage goal, a test suite (if there exists) that satisfies such +a goal is printed out in XML format, as the parameter `--xml-ui` is +given. Multiple coverage goals can share a test suite, when the +corresponding execution of the program satisfies all these goals at the +same time. + +In the end, the following test suites are automatically generated for +testing the PID controller. A test suite consists of a sequence of input +parameters that are passed to the PID function `climb_pid_run` at each +loop iteration. For example, Test 1 covers the MC/DC goal with +id="climb\_pid\_run.coverage.1". The complete output from CBMC is in +[pid\_test\_suites.xml](pid_test_suites.xml), where every test suite and +the coverage goals it is for are clearly described. + + Test suite: + Test 1. + (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f + + Test 2. + (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f + + Test 3. + (iteration 1) desired_climb=0.000000f, estimator_z_dot=-1.000000f + (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f + + Test 4. + (iteration 1) desired_climb=1.000000f, estimator_z_dot=-1.000000f + (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f + (iteration 3) desired_climb=1.000000f, estimator_z_dot=-1.000000f + (iteration 4) desired_climb=1.000000f, estimator_z_dot=-1.000000f + (iteration 5) desired_climb=0.000000f, estimator_z_dot=-1.000000f + (iteration 6) desired_climb=1.000000f, estimator_z_dot=-1.000000f + + Test 5. + (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 2) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 3) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 4) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 5) desired_climb=-1.000000f, estimator_z_dot=1.000000f + (iteration 6) desired_climb=-1.000000f, estimator_z_dot=1.000000f + +The option `--unwind 6` unwinds the loop inside the main function body +six times. In order to achieve the complete coverage on all the +instrumented goals in the PID function `climb_pid_run`, the loop must be +unwound sufficient enough times. For example, `climb_pid_run` needs to +be called at least six times for evaluating the condition +`climb_sum_err>MAX_CLIMB_SUM_ERR` in line 48 to *true*. This corresponds +to the Test 5. An introduction to the use of loop unwinding can be found +in [Understanding Loop Unwinding](cbmc-loops.shtml). + +In this small tutorial, we present the automatic test suite generation +functionality of CBMC, by applying the MC/DC code coverage criterion to +a PID controller case study. In addition to `--cover mcdc`, other +coverage criteria like `branch`, `decision`, `path` etc. are also +available when calling CBMC. + +### Coverage Criteria + +The table below summarizes the coverage criteria that CBMC supports. + +Criterion |Definition +----------|---------- +assertion |For every assertion, generate a test that reaches it +location |For every location, generate a test that reaches it +branch |Generate a test for every branch outcome +decision |Generate a test for both outcomes of every Boolean expression that is not an operand of a propositional connective +condition |Generate a test for both outcomes of every Boolean expression +mcdc |Modified Condition/Decision Coverage (MC/DC) +path |Bounded path coverage +cover |Generate a test for every `__CPROVER_cover` statement + + +\section man_satabs SATABS---Predicate Abstraction with SAT + +\subsection man_satabs-overview Overview + +This section describes SATABS from the point of view of the user. To +learn about the technology implemented in SATABS, read +\ref man_satabs-background "this". + +We assume you have already installed SATABS and the necessary support +files on your system. If not so, please follow +\ref man_install-satabs "these instructions". + +While users of SATABS almost never have to be concerned about the +underlying refinement abstraction algorithms, understanding the classes +of properties that can be verified is crucial. Predicate abstraction is +most effective when applied to *control-flow dominated properties*. As +an example, reconsider the following program (lock-example-fixed.c): + + _Bool nondet_bool(); + _Bool LOCK = 0; + + _Bool lock() { + if(nondet_bool()) { + assert(!LOCK); + LOCK=1; + return 1; } + + return 0; + } + + void unlock() { + assert(LOCK); + LOCK=0; + } + + int main() { + unsigned got_lock = 0; + int times; + + while(times > 0) { + if(lock()) { + got_lock++; + /* critical section */ + } + + if(got_lock!=0) { + unlock(); + got_lock--; + } + + times--; + } + } + +The two assertions in the program model that the functions `lock()` and +`unlock()` are called in the right order. Note that the value of `times` +is chosen non-deterministically and is not bounded. The program has no +run-time bound, and thus, unwinding the code with CBMC will never +terminate. + +### Working with Claims + +The two assertions will give rise to two *properties*. Each property is +associated to a specific line of code, i.e., a property is violated when +some condition can become false at the corresponding program location. +SATABS will generate a list of all properties for the programs as +follows: + + satabs lock-example-fixed.c --show-properties + +SATABS will list two properties; each property corresponds to one of the +two assertions. We can use SATABS to verify both properties as follows: + + satabs lock-example-fixed.c + +SATABS will conclude the verification successfully, that is, both +assertions hold for execution traces of any length. + +By default, SATABS attempts to verify all properties at once. A single +property can be verified (or refuted) by using the `--property id` +option of SATABS, where `id` denotes the identifier of the property in +the list obtained by calling SATABS with the `--show-properties` flag. +Whenever a property is violated, SATABS reports a feasible path that +leads to a state in which the condition that corresponds to the violated +property evaluates to false. + +\subsection man_satabs-libraries Programs that use Libraries + +SATABS cannot check programs that use functions that are only available +in binary (compiled) form (this restriction is not imposed by the +verification algorithms that are used by SATABS – they also work on +assembly code). The reason is simply that so far no assembly language +frontend is available for SATABS. At the moment, (library) functions for +which no C source code is available have to be replaced by stubs. The +usage of stubs and harnesses (as known from unit testing) also allows to +check more complicated properties (like, for example, whether function +`fopen` is always called before `fclose`). This technique is explained +in detail in the \ref man_satabs-tutorials "SATABS tutorials". + +\subsection man_satabs-unit-test Unit Testing with SATABS + +The example presented \ref man_satabs-tutorial-driver "here" is +obviously a toy example and can hardly be used to convince your project +manager to use static verification in your next project. Even though we +recommend to use formal verification and specification already in the +early phases of your project, the sad truth is that in most projects +verification (of any kind) is still pushed to the very end of the +development cycle. Therefore, this section is dedicated to the +verification of legacy code. However, the techniques presented here can +also be used for *unit testing*. + +Unit testing is used in most software development projects, and static +verification with SATABS can be very well combined with this technique. +Unit testing relies on a number test cases that yield the desired code +coverage. Such test cases are implemented by a software testing engineer +in terms of a test harness (aka test driver) and a set of function +stubs. Typically, a slight modification to the test harness allows it to +be used with SATABS. Replacing the explicit input values with +non-deterministic inputs (as explained in +\ref man_satabs-tutorial-aeon "here" and +\ref man_satabs-tutorial-driver "here")) guarantees that SATABS will try +to achieve **full** path and state coverage (due to the fact that +predicate abstraction implicitly detects equivalence classes). However, +it is not guaranteed that SATABS terminates in all cases. Keep in mind +that you must not make any assumptions about the validity of the +properties if SATABS did not run to completion! + +### Further Reading + +- [Model Checking Concurrent Linux Device + Drivers](http://www.kroening.com/publications/view-publications-wbwk2007.html) +- [SATABS: SAT-based Predicate Abstraction for + ANSI-C](http://www-2.cs.cmu.edu/~svc/papers/view-publications-cksy2005.html) +- [Predicate Abstraction of ANSI-C Programs using + SAT](http://www-2.cs.cmu.edu/~svc/papers/view-publications-cksy2004.html) + +\subsection man_satabs-background Background + +### Sound Abstractions + +This section provides background information on how SATABS operates. +Even for very trivial C programs it is impossible to exhaustively +examine their state space (which is potentially unbounded). However, not +all details in a C program necessarily contribute to a bug, so it may be +sufficient to only examine those parts of the program that are somehow +related to a bug. + +In practice, many static verification tools (such as `lint`) try to +achieve this goal by applying heuristics. This approach comes at a cost: +bugs might be overlooked because the heuristics do not cover all +relevant aspects of the program. Therefore, the conclusion that a +program is correct whenever such a static verification tool is unable to +find an error is invalid. + +\image html cegar-1.png "CEGAR Loop" + +A more sophisticated approach that has been very successful recently is +to generate a *sound* abstraction of the original program. In this +context, *soundness* refers to the fact that the abstract program +contains (at least) all relevant behaviors (i.e., bugs) that are present +in the original program. In the Figure above, the first component strips +details from the original program. The number of possible behaviors +increases as the number of details in the abstract program decreases. +Intuitively, the reason is that whenever the model checking tool lacks +the information that is necessary to make an accurate decision on +whether a branch of an control flow statement can be taken or not, both +branches have to be considered. + +In the resulting *abstract program*, a set of concrete states is +subsumed by means of a single abstract state. Consider the following +figure: + +![](states.png) + +The concrete states *x*~1~ and *x*~2~ are mapped to an abstract state +*X*, and similarly *Y* subsumes *y*~1~ and *y*~2~. However, all +transitions that are possible in the concrete program are also possible +in the abstract model. The abstract transition *X* → *Y* summarizes the +concrete transitions *x*~1~ → *y*~1~ and *x*~1~ → *x*~1~, and *Y* → *X* +corresponds to *x*~1~ → *x*~2~. The behavior *X* → *Y* → *X* is feasible +in the original program, because it maps to *x*~1~ → *x*~1~ → *x*~2~. +However, *Y* → *X* → *Y* is feasible only in the abstract model. + +### Spurious Counterexamples + +The consequence is that the model checker (component number two in the +figure above) possibly reports a *spurious* counterexample. We call a +counterexample spurious whenever it is feasible in the current abstract +model but not in the original program. However, whenever the model +checker is unable to find an execution trace that violates the given +property, we can conclude that there is no such trace in the original +program, either. + +The feasibility of counterexamples is checked by *symbolic simulation* +(performed by component three in the figure above). If the +counterexample is indeed feasible, SATABS found a bug in the original +program and reports it to the user. + +### Automatic Refinement + +On the other hand, infeasible counterexamples (that originate from +abstract behaviors that result from the omission of details and are not +present in the original program) are never reported to the user. +Instead, the information is used in order to refine the abstraction such +that the spurious counterexample is not part of the refined model +anymore. For instance, the reason for the infeasibility of *Y* → *X* → +*Y* is that neither *y*~1~ nor *x*~1~ can be reached from *x*~2~. +Therefore, the abstraction can be refined by partitioning *X*. + +The refinement steps can be illustrated as follows: + +![Iterative refinement](refinement.png) + +The first step (1) is to generate a very coarse abstraction with a very +small state space. This abstraction is then successively refined (2, 3, +...) until either a feasible counterexample is found or the abstract +program is detailed enough to show that there is no path that leads to a +violation of the given property. The problem is that this point is not +necessarily reached for every input program, i.e., it is possible that +the the abstraction refinement loop never terminates. Therefore, SATABS +allows to specify an upper bound for the number of iterations. + +When this upper bound is reached and no counterexample was found, this +does not necessarily mean that there is none. In this case, you cannot +make any conclusions at all with respect to the correctness of the input +program. + +\subsection man_satabs-tutorials Tutorials + +We provide an introduction to model checking "real" C programs with +SATABS using two small examples. + +\subsubsection man_satabs-tutorial-driver Reference Counting in Linux Device Drivers + +Microsoft's [SLAM](http://research.microsoft.com/SLAM) toolkit has been +successfully used to find bugs in Windows device drivers. SLAM +automatically verifies device driver whether a device driver adheres to +a set of specifications. SLAM provides a test harness for device drivers +that calls the device driver dispatch routines in a non-deterministic +order. Therefore, the Model Checker examines all combinations of calls. +Motivated by the success this approach, we provide a toy example based +on Linux device drivers. For a more complete approach to the +verification of Linux device drivers, consider +[DDVerify](http://www.cprover.org/ddverify/). + +Dynamically loadable modules enable the Linux Kernel to load device +drivers on demand and to release them when they are not needed anymore. +When a device driver is registered, the kernel provides a major number +that is used to uniquely identify the device driver. The corresponding +device can be accessed through special files in the filesystem; by +convention, they are located in the `/dev` directory. If a process +accesses a device file the kernel calls the corresponding `open`, `read` +and `write` functions of the device driver. Since a driver must not be +released by the kernel as long as it is used by at least one process, +the device driver must maintain a usage counter (in more recent Linux +kernels, this is done automatically, however, drivers that must maintain +backward compatibility have to adjust this counter). + +We provide a skeleton of such a driver. Download the files +assets/spec.c, assets/driver.c, assets/driver.h, assets/kdev_t.h, and +assets/modules.h. + +The driver contains following functions: + +1. `register_chrdev`: (in assets/spec.c) Registers a character device. + In our implementation, the function sets the variable `usecount` to + zero and returns a major number for this device (a constant, if the + user provides 0 as argument for the major number, and the value + specified by the user otherwise). + + int usecount; + + int register_chrdev (unsigned int major, const char* name) + { + usecount = 0; + if (major == 0) + return MAJOR_NUMBER; + return major; + } + +2. `unregister_chrdev`: (in assets/spec.c) Unregisters a character + device. This function asserts that the device is not used by any + process anymore (we use the macro `MOD_IN_USE` to check this). + + int unregister_chrdev (unsigned int major, const char* name) + { + if (MOD_IN_USE) + { + ERROR: assert (0); + } + else + return 0; + } + +3. `dummy_open`: (in assets/driver.c) This function increases the + `usecount`. If the device is locked by some other process + `dummy_open` returns -1. Otherwise it locks the device for the + caller. + +4. `dummy_read`: (in assets/driver.c) This function "simulates" a read + access to the device. In fact it does nothing, since we are + currently not interested in the potential buffer overflow that may + result from a call to this function. Note the usage of the function + `nondet_int`: This is an internal SATABS-function that + non­determi­nistically returns an arbitrary integer value. The + function `__CPROVER_assume` tells SATABS to ignore all traces that + do not adhere to the given assumption. Therefore, whenever the lock + is held, `dummy_read` will return a value between 0 and `max`. If + the lock is not held, then `dummy_read` returns -1. + +5. `dummy_release`: (in assets/driver.c) If the lock is held, then + `dummy_release` decreases the `usecount`, releases the lock, and + returns 0. Otherwise, the function returns -1. + +We now want to check if any *valid* sequence of calls of the dispatch +functions (in driver.c) can lead to the violation of the assertion (in +assets/spec.c). Obviously, a call to `dummy_open` that is immediately +followed by a call to `unregister_chrdev` violates the assertion. + +The function `main` in spec.c gives an example of how these functions +are called. First, a character device "`dummy`" is registered. The major +number is stored in the `inode` structure of the device. The values for +the file structure are assigned non-deterministically. We rule out +invalid sequences of calls by ensuring that no device is unregistered +while it is still locked. We use the following model checking harness +for calling the dispatching functions: + + random = nondet_uchar (); + __CPROVER_assume (0 <= random && random <= 3); + + switch (random) + { + case 1: + rval = dummy_open (&inode, &my_file); + if (rval == 0) + lock_held = TRUE; + break; + case 2: + __CPROVER_assume (lock_held); + count = dummy_read (&my_file, buffer, BUF_SIZE); + break; + case 3: + dummy_release (&inode, &my_file); + lock_held = FALSE; + break; + default: + break; + } + +The variable `random` is assigned non-deterministically. Subsequently, +the value of `random` is restricted to be 0 &le `random` ≤ 3 by a call +to `__CPROVER_assume`. Whenever the value of `random` is not in this +interval, the corresponding execution trace is simply discarded by +SATABS. Depending on the value of `random`, the harness calls either +`dummy_open`, `dummy_read` or `dummy_close`. Therefore, if there is a +sequence of calls to these three functions that leads to a violation of +the assertion in `unregister_chrdev`, then SATABS will eventually +consider it. + +If we ask SATABS to show us the properties it verifies with + + satabs driver.c spec.c --show-properties + +for our example, we obtain + +1. Claim unregister\_chrdev.1:\ +     file spec.c line 18 function unregister\_chrdev\ +     MOD\_IN\_USE in unregister\_chrdev\ +     FALSE + +2. Claim dummy\_open.1:\ +     file driver.c line 15 function dummy\_open\ +     i\_rdev mismatch\ +     (unsigned int)inode->i\_rdev >> 8 == (unsigned + int)dummy\_major + +It seems obvious that the property dummy\_open.1 can never be violated. +SATABS confirms this assumption: We call + + satabs driver.c spec.c --property dummy_open.1 + +and SATABS reports `VERIFICATION SUCCESSFUL` after a few iterations. + +If we try to verify property unregister\_chrdev.1, SATABS reports that +the property in line 18 in file spec.c is violated (i.e., the assertion +does not hold, therefore the `VERIFICATION FAILED`). Furthermore, SATABS +provides a detailed description of the problem in the form of a +counterexample (i.e., an execution trace that violates the property). On +this trace, `dummy_open` is called **twice**, leading to a `usecount` of 2. +The second call of course fails with `rval=-1`, but the counter is +increased nevertheless: + + int dummy_open (struct inode *inode, struct file *filp) + { + __CPROVER_assert(MAJOR (inode->i_rdev) == dummy_major, + "i_rdev mismatch"); + MOD_INC_USE_COUNT; + + if (locked) + return -1; + locked = TRUE; + + return 0; /* success */ + } + +Then, `dummy_release` is called to release the lock on the device. +Finally, the loop is left and the call to `unregister_chrdev` results in +a violation of the assertion (since `usecount` is still 1, even though +`locked=0`). + +\subsubsection man_satabs-tutorial-aeon Buffer Overflow in a Mail Transfer Agent + +We explain how to model check Aeon version 0.2a, a small mail transfer +agent written by Piotr Benetkiewicz. The description advertises Aeon as +a "*good choice for **hardened** or minimalistic boxes*". The sources +are available +[here](http://www.cprover.org/satabs/examples/loop_detection/aeon-0.2a.tar.gz). + +Our first naive attempt to verify Aeon using + + satabs *.c + +produces a positive result, but also warns us that the property holds +trivially. It also reveals that a large number library functions are +missing: SATABS is unable to find the source code for library functions +like `send`, `write` and `close`. + +Now, do you have to provide a body for all missing library functions? +There is no easy answer to this question, but a viable answer would be +"most likely not". It is necessary to understand how SATABS handles +functions without bodies: It simply assumes that such a function returns +an arbitrary value, but that no other locations than the one on the left +hand side of the assignment are changed. Obviously, there are cases in +which this assumption is un­sound, since the function potentially +modifies all memory locations that it can somehow address. + +We now use static analysis to generate array bounds checks for Aeon: + + satabs *.c --pointer-check --bounds-check --show-properties + +SATABS will show about 300 properties in various functions (read +\ref man_instrumentation-properties "this" for more information on the +property instrumentation). Now consider the first few lines of the +`main` function of Aeon: + + int main(int argc, char **argv) + { + char settings[MAX_SETTINGS][MAX_LEN]; + ... + numSet = getConfig(settings); + if (numSet == -1) { + logEntry("Missing config file!"); + exit(1); + } + ... + +and the function `getConfig` in `lib_aeon.c`: + + int getConfig(char settings[MAX_SETTINGS][MAX_LEN]) + { + char home[MAX_LEN]; + FILE *fp; /* .rc file handler */ + int numSet = 0; /* number of settings */ + + strcpy(home, getenv("HOME")); /* get home path */ + strcat(home, "/.aeonrc"); /* full path to rc file */ + fp = fopen(home, "r"); + if (fp == NULL) return -1; /* no cfg - ERROR */ + while (fgets(settings[numSet], MAX_LEN-1, fp) + && (numSet < MAX_SETTINGS)) numSet++; + fclose(fp); + + return numSet; + } + +The function `getConfig` makes calls to `strcpy`, `strcat`, `getenv`, +`fopen`, `fgets`, and `fclose`. It is very easy to provide an +implementation for the functions from the string library (string.h), and +SATABS comes with meaningful definitions for most of them. The +definition of `getenv` is not so straight-forward. The man-page of +`getenv` (which we obtain by entering `man 3 getenv` in a Unix or cygwin +command prompt) tells us: + + `` `getenv' `` searches the list of en­vi­ron­ment variable names + and values (using the global pointer `char **environ`) for a + variable whose name matches the string at `NAME`. If a variable name + matches, `getenv` returns a pointer to the associated value. + +SATABS has no information whatsoever about the content of `environ`. +Even if SATABS could access the environment variables on your +computer, a successful verification of `Aeon` would then only guarantee +that the properties for this program hold on your computer with a +specific set of en­vi­ron­ment variables. We have to assume that +`environ` contains en­vi­ron­ment variables that have an arbitrary +content of arbitrary length. The content of en­vi­ron­ment variables is +not only arbitrary but could be malefic, since it can be modified by the +user. The approximation of the behavior of `getenv` that is shipped with +SATABS completely ignores the content of the string. + +Now let us have another look at the properties that SATABS generates for +the models of the the string library and for `getenv`. Most of these +properties require that we verify that the upper and lower bounds of +buffers or arrays are not violated. Let us look at one of the properties +that SATABS generates for the code in function `getConfig`: + + Claim getConfig.3:   file lib_aeon.c line 19 function getConfig   dereference failure: NULL plus offset pointer   !(SAME-OBJECT(src, NULL))` + +The model of the function `strcpy` dereferences the pointer returned by +`getenv`, which may return a NULL pointer. This possibility is detected +by the static analysis, and thus a corresponding property is generated. +Let us check this specific property: + + satabs *.c --pointer-check --bounds-check --property getConfig.3 + +SATABS immediately returns a counterexample path that demonstrates how +`getenv` returns a NULL, which is subsequently dereferenced. We have +identified the first bug in this program: it requires that the +environment variable HOME is set, and crashes otherwise. + +Let us examine one more property in the same function: + + Claim getConfig.7:   file lib_aeon.c line 19 function getConfig   dereference failure: array `home' upper bound   !(POINTER_OFFSET(dst) + (int)i >= 512) || !(SAME-OBJECT(dst, &home[0])) + +This property asserts that the upper bound of the array `home` is not +violated. The variable `home` looks familiar: We encountered it in the +function `getConfig` given above. The function `getenv` in combination +with functions `strcpy`, `strcat` or `sprintf` is indeed often the +source for buffer overflows. Therefore, we try to use SATABS to check +the upper bound of the array `home`: + + satabs *.c --pointer-check --bounds-check --property getConfig.7 + +SATABS runs for quite a while and will eventually give up, telling us +that its upper bound for abstraction refinement iterations has been +exceeded. This is not exactly the result we were hoping for, and we +could now increase the bound for iterations with help of the +`--iterations` command line switch of SATABS. + +Before we do this, let us investigate why SATABS has failed to provide a +useful result. The function `strcpy` contains a loop that counts from 1 +to the length of the input string. Predicate abstraction, the mechanism +SATABS is based on, is unable to detect such loops and will therefore +unroll the loop body as often as necessary. The array `home` has +`MAX_LEN` elements, and `MAX_LEN` is defined to be 512 in `aeon.h`. +Therefore, SATABS would have to run through at least 512 iterations, +only to verify (or reject) one of the more than 300 properties! Does +this fact defeat the purpose of static verification? + +We can make the job easier: after reducing the value of `MAX_LEN` in +`aeon.h` to a small value, say to 10, SATABS provides a counterexample +trace that demonstrates how the buffer overflow be reproduced. If you +use the Eclipse plugin (as described \ref man_install-eclipse "here"), +you can step through this counterexample. The trace contains the string +that is returned by `getenv`. + + +\section man_modelling Modelling + +\subsection man_modelling-nondet Nondeterminism + +### Rationale + +Programs typically read inputs from an environment. These inputs can +take the form of data read from a file, keyboard or network socket, or +arguments passed on the command line. It is usually desirable to analyze +the program for any choice of these inputs. In Model Checking, inputs +are therefore modeled by means of *nondeterminism*, which means that the +value of the input is not specified. The program may follow any +computation that results from any choice of inputs. + +### Sources of Nondeterminism + +The CPROVER tools support the following sources of nondeterminism: + +- functions that read inputs from the environments; +- the thread schedule in concurrent programs; +- initial values of local-scoped variables and memory allocated with + `malloc`; +- initial values of variables that are `extern` in all compilation + units; +- explicit functions for generating nondeterminism. + +The CPROVER tools are shipped with a number of stubs for the most +commonly used library functions. When executing a statement such as +`getchar()`, a nondeterministic value is chosen instead of reading a +character from the keyboard. + +When desired, nondeterminism can be introduced explicitly into the +program by means of functions that begin with the prefix `nondet_`. As +an example, the following function returns a nondeterministically chosen +unsigned short int: + + unsigned short int nondet_ushortint(); + +Note that the body of the function is not defined. The name of the +function itself is irrelevant (save for the prefix), but must be unique. +Also note that a nondeterministic choice is not to be confused with a +probabilistic (or random) choice. + +### Uninterpreted Functions + +It may be necessary to check parts of a program independently. +Nondeterminism can be used to over-approximate the behaviour of part of +the system which is not being checked. Rather than calling a complex or +unrelated function, a nondeterministic stub is used. However, separate +calls to the function can return different results, even for the same +inputs. If the function output only depends on its inputs then this can +introduce spurious errors. To avoid this problem, functions whose names +begin with the prefix `__CPROVER_uninterpreted_` are treated as +uninterpreted functions. Their value is non-deterministic but different +invocations will return the same value if their inputs are the same. +Note that uninterpreted functions are not supported by all back-end +solvers. + +\subsection man_modelling-assumptions Modeling with Assertions and Assumptions + +### Assertions + +[Assertions](http://en.wikipedia.org/wiki/Assertion_%28computing%29) are +statements within the program that attempt to capture the programmer's +intent. The ANSI-C standard defines a header file +[assert.h](http://en.wikipedia.org/wiki/Assert.h), which offers a macro +`assert(cond)`. When executing a statement such as + + assert(p!=NULL); + +the execution is aborted with an error message if the condition +evaluates to *false*, i.e., if `p` is NULL in the example above. The +CPROVER tools can check the validity of the programmer-annotated +assertions statically. Specifically, the CPROVER tools will check that +the assertions hold for *any* nondeterministic choice that the program +can make. The static assertion checks can be disabled using the +`--no-assertions` command line option. + +In addition, there is a CPROVER-specific way to specify assertions, +using the built-in function `__CPROVER_assert`: + + __CPROVER_assert(p!=NULL, "p is not NULL"); + +The (mandatory) string that is passed as the second argument provides an +informal description of the assertion. It is shown in the list of +properties together with the condition. + +The assertion language of the CPROVER tools is identical to the language +used for expressions. Note that \ref man_modelling-nondet +"nondeterminism" +can be exploited in order to check a range of choices. As an example, +the following code fragment asserts that **all** elements of the array +are zero: + + int a[100], i; + + ... + + i=nondet_uint(); + if(i>=0 && i<100) + assert(a[i]==0); + +The nondeterministic choice will guess the element of the array that is +nonzero. The code fragment above is therefore equivalent to + + int a[100], i; + + ... + + for(i=0; i<100; i++) + assert(a[i]==0); + +Future CPROVER releases will support explicit quantifiers with a syntax +that resembles Spec\#: + + __CPROVER_forall { *type identifier* ; *expression* } + __CPROVER_exists { *type identifier* ; *expression* } + +### Assumptions + +Assumptions are used to restrict nondeterministic choices made by the +program. As an example, suppose we wish to model a nondeterministic +choice that returns a number from 1 to 100. There is no integer type +with this range. We therefore use \_\_CPROVER\_assume to restrict the +range of a nondeterministically chosen integer: + + unsigned int nondet_uint(); + + unsigned int one_to_hundred() + { + unsigned int result=nondet_uint(); + __CPROVER_assume(result>=1 && result<=100); + return result; + } + +The function above returns the desired integer from 1 to 100. You must +ensure that the condition given as an assumption is actually satisfiable +by some nondeterministic choice, or otherwise the model checking step +will pass vacuously. + +Also note that assumptions are never retroactive: They only affect +assertions (or other properties) that follow them in program order. This +is best illustrated with an example. In the following fragment, the +assumption has no effect on the assertion, which means that the +assertion will fail: + + x=nondet_uint(); + assert(x==100); + __CPROVER_assume(x==100); + +Assumptions do restrict the search space, but only for assertions that +follow. As an example, the following program will pass: + + int main() { + int x; + + __CPROVER_assume(x>=1 && x<=100000); + + x*=-1; + + __CPROVER_assert(x<0, "x is negative"); + } + +Beware that nondeterminism cannot be used to obtain the effect of +universal quantification in assumptions. As an example, + + int main() { + int a[10], x, y; + + x=nondet_int(); + y=nondet_int(); + __CPROVER_assume(x>=0 && x<10 && y>=0 && y<10); + + __CPROVER_assume(a[x]>=0); + + assert(a[y]>=0); + } + +fails, as there is a choice of x and y which results in a counterexample +(any choice in which x and y are different). + +\subsection man_modelling-pointers Pointer Model + +### Pointers in C + +C programs (and sometimes C++ programs as well) make intensive use of +pointers in order to decouple program code from specific data. A pointer +variable does not store data such as numbers or letters, but instead +points to a location in memory that hold the relevant data. This section +describes the way the CPROVER tools model pointers. + +### Objects and Offsets + +The CPROVER tools represent pointers as a pair. The first member of the +pair is the *object* the pointer points to, and the second is the offset +within the object. + +In C, objects are simply continuous fragments of memory (this definition +of "object" is not to be confused with the use of the term in +object-oriented programming). Variables of any type are guaranteed to be +stored as one object, irrespectively of their type. As an example, all +members of a struct or array belong to the same object. CPROVER simply +assigns a number to each active object. The object number of a pointer +`p` can be extracted using the expression `__CPROVER_POINTER_OBJECT(p)`. +As a consequence, pointers to different objects are always different, +which is not sound. + +The offset (the second member of the pair that forms a pointer) is +relative to the beginning of the object; it uses byte granularity. As an +example, the code fragment + + unsigned array[10]; + char *p; + + p=(char *)(array+1); + p++; + +will result in a pointer with offset 5. The offset of a pointer `p` can +be extracted using the expression `__CPROVER_POINTER_OFFSET(p)`. + +### Dereferencing Pointers + +The CPROVER tools require that pointers that are dereferenced point to a +valid object. Assertions that check this requirement can be generated +using the option --pointer-check and, if desired, --bounds-check. These +options will ensure that NULL pointers are not dereferenced, and that +dynamically allocated objects have not yet been deallocated. + +Furthermore, the CPROVER tools check that dynamically allocated memory +is not deallocated twice. The goto-instrument tool is also able to add +checks for memory leaks, i.e., it detects dynamically allocated objects +that are not deallocated once the program terminates. + +The CPROVER tools support pointer typecasts. Most casts are supported, +with the following exceptions: + +1. One notable exception is that pointers can only be accessed using a + pointer type. The conversion of a pointer into an integer-type using + a pointer typecast is not supported. + +2. Casts from integers to pointers yield a pointer that is either NULL + (if the integer is zero) or that point into a special array for + modeling [memory-mapped + I/O](http://en.wikipedia.org/wiki/Memory-mapped_I/O). Such pointers + are assumed not to overlap with any other objects. This is, of + course, only sound if a corresponding range check is instrumented. + +3. Accesses to arrays via pointers that have the array subtype need to + be well-aligned. + +### Pointers in Open Programs + +It is frequently desired to validate an open program, i.e., a fragment +of a program. Some variables are left undefined. In case an undefined +pointer is dereferenced, CBMC assumes that the pointer points to a +separate object of appropriate type with unbounded size. The object is +assumed not to alias with any other object. This assumption may +obviously be wrong in specific extensions of the program. + +\subsection man_modelling-floating-point Floating Point + +The CPROVER tools support bit-accurate reasoning about IEEE-754 +floating-point and fixed-point arithmetic. The C standard contains a +number of areas of implementation-defined behaviour with regard to +floating-point arithmetic: + +- CPROVER supports C99 Appendix F, and thus, the `__STD_IEC_559__` + macro is defined. This means that the C `float` data type maps to + IEEE 754 `binary32` and `double` maps to `binary64` and operations + on them are as specified in IEEE 754. + +- `long double` can be configured to be `binary64`, `binary128` + (quad precision) or a 96 bit type with 15 exponent bits and 80 + significant bits. The last is an approximation of Intel's x87 + extended precision double data type. As the C standard allows a + implementations a fairly wide set of options for `long double`, it + is best avoided for both portable code and bit-precise analysis. The + default is to match the build architecture as closely as possible. + +- In CPROVER, floating-point expressions are evaluated at the 'natural + precision' (the greatest of the arguments) and not at a + higher precision. This corresponds to `FLT_EVAL_METHOD` set to `0`. + Note that this is a different policy to some platforms (see below). + +- Expression contraction (for example, converting `x * y + c` to + `fma(x,y,c)`) is not performed. In effect, the `FP_CONTRACT` pragma + is always off. + +- Constant expressions are evaluated at \`run' time wherever possible + and so will respect changes in the rounding mode. In effect, the + `FENV_ACCESS` pragma is always off. Note that floating point + constants are treated as doubles (unless they are followed by `f` + when they are float) as specified in the C standard. `goto-cc` + supports `-fsingle-precision-constant`, which allows + the (non-standard) treatment of constants as floats. + +- Casts from int to float and float to float make use of the current + rounding mode. Note that the standard requires that casts from float + to int use round-to-zero (i.e. truncation). + +### x86 and Other Platform-specific Issues + +Not all platforms have the same implementation-defined behaviour as +CPROVER. This can cause mismatches between the verification environment +and the execution environment. If this occurs, check the compiler manual +for the choices listed above. There are two common cases that can cause +these problems: 32-bit x86 code and the use of unsafe optimisations. + +Many compilers that target 32-bit x86 platforms employ a different +evaluation method. The extended precision format of the x87 unit is used +for all computations regardless of their native precision. Most of the +time, this results in more accurate results and avoids edge cases. +However, it can result in some obscure and difficult to debug behaviour. +Checking if the `FLT_EVAL_METHOD` macro is non-zero (for these platforms +it will typically be 2), should warn of these problems. Changing the +compiler flags to use the SSE registers will resolve many of them, give +a more standards-compliant platform and will likely perform better. Thus +it is *highly* recommended. Use `-msse2 -mfpmath=sse` to enable this +option for GCC. Visual C++ does not have an option to force the +exclusive use of SSE instructions, but `/arch:SSE2` will pick SSE +instructions "when it \[the compiler\] determines that it is faster to +use the SSE/SSE2 instructions" and is thus better than `/arch:IA32`, +which exclusively uses the x87 unit. + +The other common cause of discrepancy between CPROVER results and the +actual platform are the use of unsafe optimisations. Some higher +optimisation levels enable transformations that are unsound with respect +to the IEEE-754 standard. Consult the compiler manual and disable any +optimisations that are described as unsafe (for example, the GCC options +`-ffast-math`). The options `-ffp-contract=off` (which replaces +`-mno-fused-madd`), `-frounding-math` and `-fsignaling-nans` are needed +for GCC to be strictly compliant with IEEE-754. + +### Rounding Mode + +CPROVER supports the four rounding modes given by IEEE-754 1985; round +to nearest (ties to even), round up, round down and round towards zero. +By default, round to nearest is used. However, command line options +(`--round-to-zero`, etc.) can be used to over-ride this. If more control +is needed, CPROVER has models of `fesetround` (for POSIX systems) and +`_controlfp` (for Windows), which can be used to change the rounding +mode during program execution. Furthermore, the inline assembly commands +fstcw/fnstcw/fldcw (on x86) can be used. + +The rounding mode is stored in the (thread local) variable +`__CPROVER_rounding_mode`, but users are strongly advised not to use +this directly. + +### Math Library + +CPROVER implements some of `math.h`, including `fabs`, `fpclassify` and +`signbit`. It has very limited support for elementary functions. Care +must be taken when verifying properties that are dependent on these +functions as the accuracy of implementations can vary considerably. The +C compilers can (and many do) say that the accuracy of these functions +is unknown. + +### Fixed-point Arithmetic + +CPROVER also has support for fixed-point types. The `--fixedbv` flag +switches `float`, `double` and `long double` to fixed-point types. The +length of these types is platform specific. The upper half of each type +is the integer component and the lower half is the fractional part. + + +\section man_hard-soft Hardware and Software Equivalence and Co-Verification + +\subsection man_hard-soft-introduction Introduction + +A common hardware design approach employed by many companies is to first +write a quick prototype that behaves like the planned circuit in a +language like ANSI-C. This program is then used for extensive testing +and debugging, in particular of any embedded software that will later on +be shipped with the circuit. An example is the hardware of a cell phone +and its software. After testing and debugging of the program, the actual +hardware design is written using hardware description languages like +[VHDL](http://en.wikipedia.org/wiki/VHDL) or +[Verilog](http://en.wikipedia.org/wiki/Verilog). + +Thus, there are two implementations of the same design: one written in +ANSI-C, which is written for simulation, and one written in register +transfer level HDL, which is the actual product. The ANSI-C +implementation is usually thoroughly tested and debugged. + +Due to market constraints, companies aim to sell the chip as soon as +possible, i.e., shortly after the HDL implementation is designed. There +is usually little time for additional debugging and testing of the HDL +implementation. Thus, an automated, or nearly automated way of +establishing the consistency of the HDL implementation is highly +desirable. + +This motivates the verification problem: we want to verify the +consistency of the HDL implementation, i.e., the product, [using the +ANSI-C implementation as a +reference](http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=936243&userType=inst). +Es­ta­bli­shing the consistency does not re­quire a formal +specification. However, formal methods to verify either the hardware or +software design are still desirable. + +### Related Work + +There have been several attempts in the past to tackle the problem. +[Semeria et al.](http://portal.acm.org/citation.cfm?id=513951) describe +a tool for verifying the combinational equivalence of RTL-C and an HDL. +They translate the C code into HDL and use standard equivalence checkers +to establish the equivalence. The C code has to be very close to a +hardware description (RTL level), which implies that the source and +target have to be implemented in a very similar way. There are also +variants of C specifically for this purpose. The [SystemC +standard](http://en.wikipedia.org/wiki/SystemC) defines a subset of C++ +that can be used for synthesis. Further variants of ANSI-C for +specifying hardware are SpecC and Handel C, among others. + +The concept of verifying the equivalence of a software implementation +and a synchronous transition system was introduced by [Pnueli, Siegel, +and Shtrichman](http://www.springerlink.com/content/ah5lpxaagrjp8ax2/). +The C program is re­quired to be in a very specific form, since a +mechanical translation is assumed. + +In 2000, [Currie, Hu, and +Rajan](http://doi.acm.org/10.1145/337292.337339) transform DSP assembly +language into an equation for the Stanford Validity Checker. The +symbolic execution of programs for comparison with RTL is now common +practice. + +The previous work focuses on a small subset of ANSI-C that is +particularly close to register transfer language. Thus, the designer is +often re­quired to rewrite the C program manually in order to comply +with these constraints. We extend the methodology to handle the full set +of ANSI-C language features. This is a challenge in the presence of +complex, dynamic data structures and pointers that may dynamically point +to multiple objects. Furthermore, our methodology allows arbitrary loop +constructs. + +### Further Material + +We provide a small \ref man_hard-soft-tutorial "tutorial" and a +description on +\ref man_hard-soft-inputs "how to synchronize inputs between the C model and the Verilog model". +There is also a collection of +[benchmark problems](http://www.cprover.org/hardware/sequential-equivalence/) +available. + +Further Reading + +- [Hardware Verification using ANSI-C Programs as a + Reference](http://www-2.cs.cmu.edu/~svc/papers/view-publications-ck03.html) +- [Behavioral Consistency of C and Verilog Programs Using Bounded + Model Checking](http://www-2.cs.cmu.edu/~svc/papers/view-publications-cky03.html) +- [A Tool for Checking ANSI-C + Programs](http://www-2.cs.cmu.edu/~svc/papers/view-publications-ckl2004.html) +- [Checking Consistency of C and Verilog using Predicate Abstraction + and Induction](http://www.kroening.com/publications/view-publications-kc2004.html) + + +\subsection man_hard-soft-tutorial Tutorial + +### Verilog vs. ANSI-C + +We assume that CBMC is installed on your system. If not so, follow +\ref man_install-cbmc "these instructions". + +The following Verilog module implements a 4-bit counter +(counter.v): + + module top(input clk); + + reg [3:0] counter; + + initial counter=0; + + always @(posedge clk) + counter=counter+1; + + endmodule + +HW-CBMC can take Verilog modules as the one above as additional input. +Similar as in co-simulation, the data in the Verilog modules is +available to the C program by means of global variables. For the example +above, the following C fragment shows the definition of the variable +that holds the value of the `counter` register: + + struct module_top { + unsigned int counter; + }; + + extern struct module_top top; + +Using this definition, the value of the `counter` register in the +Verilog fragment above can be accessed as `top.counter`. Please note +that the name of the variable **must** match the name of the top module. +The C program only has a view of one state of the Verilog model. The +Verilog model makes a transition once the function `next_timeframe()` is +called. + +As CBMC performs Bounded Model Checking, the number of timeframes +available for analysis must be bounded (SATABS). As it is desirable to +change the bound to adjust it to the available computing capacity, the +bound is given on the command line and not as part of the C program. +This makes it easy to use only one C program for arbitrary bounds. The +actual bound is available in the C program using the following +declaration: + + extern const unsigned int bound; + +Also note that the fragment above declares a constant variable of struct +type. Thus, the C program can only read the trace values and is not able +to modify them. We will later on describe how to drive inputs of the +Verilog module from within the C program. + +As described in previous chapters, assertions can be used to verify +properties of the Verilog trace. As an example, the following program +checks two values of the trace of the counter module (counter.c): + + void next_timeframe(); + + struct module_top { + unsigned int counter; + }; + + extern struct module_top top; + + int main() { + next_timeframe(); + next_timeframe(); + assert(top.counter==2); + next_timeframe(); + assert(top.counter==3); + } + +The following CBMC command line checks these assertions with a bound of +20: + + hw-cbmc counter.c counter.v --module top --bound 20 + +Note that a specific version of CBMC is used, called `hw-cbmc`. The +module name given must match the name of the module in the Verilog file. +Multiple Verilog files can be given on the command line. + +The `--bound` parameter is not to be confused with the `--unwind` +parameter. While the `--unwind` parameter specifies the maximum +unwinding depth for loops within the C program, the `--bound` parameter +specifies the number of times the transition relation of the Verilog +module is to be unwound. + +### Counterexamples + +For the given example, the verification is successful. If the first +assertion is changed to + + assert(top.counter==10); + +and the bound on the command line is changed to 6, CBMC will produce a +counterexample. CBMC produces two traces: One for the C program, which +matches the traces described earlier, and a separate trace for the +Verilog module. The values of the registers in the Verilog module are +also shown in the C trace as part of the initial state. + + Initial State + ---------------------------------------------------- + bound=6 (00000000000000000000000000000110) + counter={ 0, 1, 2, 3, 4, 5, 6 } + + Failed assertion: assertion line 6 function main + + Transition system state 0 + ---------------------------------------------------- + counter=0 (0000) + + Transition system state 1 + ---------------------------------------------------- + counter=1 (0001) + + Transition system state 2 + ---------------------------------------------------- + counter=2 (0010) + + Transition system state 3 + ---------------------------------------------------- + counter=3 (0011) + + Transition system state 4 + ---------------------------------------------------- + counter=4 (0100) + + Transition system state 5 + ---------------------------------------------------- + counter=5 (0101) + + Transition system state 6 + ---------------------------------------------------- + counter=6 (0110) + +### Using the Bound + +The following program is using the bound variable to check the counter +value in all cycles: + + void next_timeframe(); + extern const unsigned int bound; + + struct module_top { + unsigned int counter; + }; + + extern struct module_top top; + + int main() { + unsigned cycle; + + for(cycle=0; cycle + #include + + int main() { + printf("sizeof(long int): %d\n", (int)sizeof(long int)); + printf("sizeof(int *): %d\n", (int)sizeof(int *)); + assert(0); + } + +The counterexample trace contains the strings printed by the `printf` +command. + +The effects of endianness are more subtle. Try the following program +with `--big-endian` and `--little-endian`: + + #include + #include + + int main() { + int i=0x01020304; + char *p=(char *)&i; + printf("Bytes of i: %d, %d, %d, %d\n", p[0], p[1], p[2], p[3]); + assert(0); + } + + +\subsection man_instrumentation-properties Property Instrumentation + +### Properties + +We have mentioned *properties* several times so far, but we never +explained *what* kind of properties CBMC and SATABS can verify. We cover +this topic in more detail in this section. + +Both CBMC and SATABS use +[assertions](http://en.wikipedia.org/wiki/Assertion_(computing)) to +specify program properties. Assertions are properties of the state of +the program when the program reaches a particular program location. +Assertions are often written by the programmer by means of the `assert` +macro. + +In addition to the assertions written by the programmer, assertions for +specific properties can also be generated automatically by CBMC and +SATABS, often relieving the programmer from writing "obvious" +assertions. + +CBMC and SATABS come with an assertion generator called +`goto-instrument`, which performs a conservative [static +analysis](http://en.wikipedia.org/wiki/Static_code_analysis) to +determine program locations that potentially contain a bug. Due to the +imprecision of the static analysis, it is important to emphasize that +these generated assertions are only *potential* bugs, and that the Model +Checker first needs to confirm that they are indeed genuine bugs. + +The assertion generator can generate assertions for the verification of +the following properties: + +- **Buffer overflows.** For each array access, check whether the upper + and lower bounds are violated. +- **Pointer safety.** Search for `NULL`-pointer dereferences or + dereferences of other invalid pointers. + +- **Division by zero.** Check whether there is a division by zero in + the program. + +- **Not-a-Number.** Check whether floating-point computation may + result in [NaNs](http://en.wikipedia.org/wiki/NaN). + +- **Unitialized local.** Check whether the program uses an + uninitialized local variable. + +- **Data race.** Check whether a concurrent program accesses a shared + variable at the same time in two threads. + +We refrain from explaining the properties above in detail. Most of them +relate to behaviors that are left undefined by the respective language +semantics. For a discussion on why these behaviors are usually very +undesirable, read [this](http://blog.regehr.org/archives/213) blog post +by John Regehr. + +All the properties described above are *reachability* properties. They +are always of the form + +"*Is there a path through the program such that property ... is +violated?*" + +The counterexamples to such properties are always program paths. Users +of the Eclipse plugin can step through these counterexamples in a way +that is similar to debugging programs. The installation of this plugin +is explained \ref man_install-eclipse "here". + +### Using goto-instrument + +The goto-instrument static analyzer operates on goto-binaries, which is +a binary representation of control-flow graphs. The goto-binary is +extracted from program source code using goto-cc, which is explained +\ref man_instrumentation-goto-cc "here". Given a goto-program, +goto-instrument operates as follows: + +1. A goto-binary is read in. +2. The specified static analyses are performed. +3. Any potential bugs found are transformed into corresponding + assertions, and are added into the program. +4. A new goto-binary (with assertions) is written to disc. + +As an example, we begin with small C program we call `expr.c` (taken +from [here](http://www.spinroot.com/uno/)): + + int *ptr; + + int main(void) { + if (ptr) + *ptr = 0; + if (!ptr) + *ptr = 1; + } + +The program contains an obvious NULL-pointer dereference. We first +compile the example program with goto-cc and then instrument the +resulting goto-binary with pointer checks. + + goto-cc expr.c -o in.gb   goto-instrument in.gb out.gb --pointer-check + +We can now get a list of the assertions that have been generated as +follows: + + goto-instrument out.gb --show-properties + +Using either CBMC or SATABS on `out.gb`, we can obtain a counterexample +trace for the NULL-pointer dereference: + + cbmc out.gb + +The goto-instrument program supports the following checks: + +Flag | Check +-----------------------------|---------------------------------------------- +`--no-assertions` | ignore user assertions +`--bounds-check` | add array bounds checks +`--div-by-zero-check` | add division by zero checks +`--pointer-check` | add pointer checks +`--signed-overflow-check` | add arithmetic over- and underflow checks +`--unsigned-overflow-check` | add arithmetic over- and underflow checks +`--undefined-shift-check` | add range checks for shift distances +`--nan-check` | add floating-point NaN checks +`--uninitialized-check` | add checks for uninitialized locals (experimental) +`--error-label label` | check that given label is unreachable + +\subsection man_instrumentation-api The CPROVER API Reference + +The following sections summarize the functions available to programs +that are passed to the CPROVER tools. + +### Functions + +#### \_\_CPROVER\_assume, \_\_CPROVER\_assert, assert + + void __CPROVER_assume(_Bool assumption); + void __CPROVER_assert(_Bool assertion, const char *description); + void assert(_Bool assertion); + +The function **\_\_CPROVER\_assume** adds an expression as a constraint +to the program. If the expression evaluates to false, the execution +aborts without failure. More detail on the use of assumptions is in the +section on [Assumptions and Assertions](modeling-assertions.shtml). + +#### \_\_CPROVER\_same\_object, \_\_CPROVER\_POINTER\_OBJECT, \_\_CPROVER\_POINTER\_OFFSET, \_\_CPROVER\_DYNAMIC\_OBJECT + + _Bool __CPROVER_same_object(const void *, const void *); + unsigned __CPROVER_POINTER_OBJECT(const void *p); + signed __CPROVER_POINTER_OFFSET(const void *p); + _Bool __CPROVER_DYNAMIC_OBJECT(const void *p); + +The function **\_\_CPROVER\_same\_object** returns true if the two +pointers given as arguments point to the same object. The function +**\_\_CPROVER\_POINTER\_OFFSET** returns the offset of the given pointer +relative to the base address of the object. The function +**\_\_CPROVER\_DYNAMIC\_OBJECT** returns true if the pointer passed as +arguments points to a dynamically allocated object. + +#### \_\_CPROVER\_is\_zero\_string, \_\_CPROVER\_zero\_string\_length, \_\_CPROVER\_buffer\_size + + _Bool __CPROVER_is_zero_string(const void *); + __CPROVER_size_t __CPROVER_zero_string_length(const void *); + __CPROVER_size_t __CPROVER_buffer_size(const void *); + +#### \_\_CPROVER\_initialize + + void __CPROVER_initialize(void); + +The function **\_\_CPROVER\_initialize** computes the initial state of +the program. It is called prior to calling the main procedure of the +program. + +#### \_\_CPROVER\_input, \_\_CPROVER\_output + + void __CPROVER_input(const char *id, ...); + void __CPROVER_output(const char *id, ...); + +The functions **\_\_CPROVER\_input** and **\_\_CPROVER\_output** are +used to report an input or output value. Note that they do not generate +input or output values. The first argument is a string constant to +distinguish multiple inputs and outputs (inputs are typically generated +using nondeterminism, as described [here](modeling-nondet.shtml)). The +string constant is followed by an arbitrary number of values of +arbitrary types. + +#### \_\_CPROVER\_cover + + void __CPROVER_cover(_Bool condition); + +This statement defines a custom coverage criterion, for usage with the +[test suite generation feature](cover.shtml). + +#### \_\_CPROVER\_isnan, \_\_CPROVER\_isfinite, \_\_CPROVER\_isinf, \_\_CPROVER\_isnormal, \_\_CPROVER\_sign + + _Bool __CPROVER_isnan(double f); + _Bool __CPROVER_isfinite(double f); + _Bool __CPROVER_isinf(double f); + _Bool __CPROVER_isnormal(double f); + _Bool __CPROVER_sign(double f); + +The function **\_\_CPROVER\_isnan** returns true if the double-precision +floating-point number passed as argument is a +[NaN](http://en.wikipedia.org/wiki/NaN). + +The function **\_\_CPROVER\_isfinite** returns true if the +double-precision floating-point number passed as argument is a finite +number. + +This function **\_\_CPROVER\_isinf** returns true if the +double-precision floating-point number passed as argument is plus or +minus infinity. + +The function **\_\_CPROVER\_isnormal** returns true if the +double-precision floating-point number passed as argument is a normal +number. + +This function **\_\_CPROVER\_sign** returns true if the double-precision +floating-point number passed as argument is negative. + +#### \_\_CPROVER\_abs, \_\_CPROVER\_labs, \_\_CPROVER\_fabs, \_\_CPROVER\_fabsl, \_\_CPROVER\_fabsf + + int __CPROVER_abs(int x); + long int __CPROVER_labs(long int x); + double __CPROVER_fabs(double x); + long double __CPROVER_fabsl(long double x); + float __CPROVER_fabsf(float x); + +These functions return the absolute value of the given argument. + +#### \_\_CPROVER\_array\_equal, \_\_CPROVER\_array\_copy, \_\_CPROVER\_array\_set + + _Bool __CPROVER_array_equal(const void array1[], const void array2[]); + void __CPROVER_array_copy(const void dest[], const void src[]); + void __CPROVER_array_set(const void dest[], value); + +The function **\_\_CPROVER\_array\_equal** returns true if the values +stored in the given arrays are equal. The function +**\_\_CPROVER\_array\_copy** copies the contents of the array **src** to +the array **dest**. The function **\_\_CPROVER\_array\_set** initializes +the array **dest** with the given value. + +#### Uninterpreted Functions + +Uninterpreted functions are documented \ref man_modelling-nondet "here". + +### Predefined Types and Symbols + +#### \_\_CPROVER\_bitvector + + __CPROVER_bitvector [ expression ] + +This type is only available in the C frontend. It is used to specify a +bit vector with arbitrary but fixed size. The usual integer type +modifiers **signed** and **unsigned** can be applied. The usual +arithmetic promotions will be applied to operands of this type. + +#### \_\_CPROVER\_floatbv + + __CPROVER_floatbv [ expression ] [ expression ] + +This type is only available in the C frontend. It is used to specify an +IEEE-754 floating point number with arbitrary but fixed size. The first +parameter is the total size (in bits) of the number, and the second is +the size (in bits) of the mantissa, or significand (not including the +hidden bit, thus for single precision this should be 23). + +#### \_\_CPROVER\_fixedbv + + __CPROVER_fixedbv [ expression ] [ expression ] + +This type is only available in the C frontend. It is used to specify a +fixed-point bit vector with arbitrary but fixed size. The first +parameter is the total size (in bits) of the type, and the second is the +number of bits after the radix point. + +#### \_\_CPROVER\_size\_t + +The type of sizeof expressions. + +#### \_\_CPROVER\_rounding\_mode + + extern int __CPROVER_rounding_mode; + +This variable contains the IEEE floating-point arithmetic rounding mode. + +#### \_\_CPROVER\_constant\_infinity\_uint + +This is a constant that models a large unsigned integer. + +#### \_\_CPROVER\_integer, \_\_CPROVER\_rational + +**\_\_CPROVER\_integer** is an unbounded, signed integer type. +**\_\_CPROVER\_rational** is an unbounded, signed rational number type. + +#### \_\_CPROVER\_memory + + extern unsigned char __CPROVER_memory[]; + +This array models the contents of integer-addressed memory. + +#### \_\_CPROVER::unsignedbv<N> (C++ only) + +This type is the equivalent of **unsigned \_\_CPROVER\_bitvector\[N\]** +in the C++ front-end. + +#### \_\_CPROVER::signedbv<N> (C++ only) + +This type is the equivalent of **signed \_\_CPROVER\_bitvector\[N\]** in +the C++ front-end. + +#### \_\_CPROVER::fixedbv<N> (C++ only) + +This type is the equivalent of **\_\_CPROVER\_fixedbv\[N,m\]** in the +C++ front-end. + +### Concurrency + +Asynchronous threads are created by preceding an instruction with a +label with the prefix **\_\_CPROVER\_ASYNC\_**. + +\subsection man_goto-cc-linux goto-cc: Extracting Models from the Linux Kernel + +The Linux kernel code consists of more than 11 million lines of +low-level C and is frequently used to evaluate static analysis +techniques. In the following, we show how to extract models from Linux +2.6.39. + +1. First of all, you will need to make sure you have around 100 GB of + free disc space available. + +2. Download the Kernel sources at + . + +3. Now do + +   `bunzip2 linux-2.6.39.tar.bz2`\ +   `tar xvf linux-2.6.39.tar`\ +   `cd linux-2.6.39` + +4. Now ensure that you can actually compile a kernel by doing + +   `make defconfig`\ +   `make` + + These steps need to succeed before you can try to extract models + from the kernel. + +5. Now compile [gcc-wrap.c](gcc-wrap.c) and put the resulting binary + into a directory that is in your PATH variable: + +   `lwp-download http://www.cprover.org/cprover-manual/gcc-wrap.c`\ +   `gcc gcc-wrap.c -o gcc-wrap`\ +   `cp gcc-wrap ~/bin/`\ + + This assumes that the directory `~/bin` exists and is in your + PATH variable. + +6. Now change the variable CC in the kernel Makefile as follows: + + CC = ~/bin/gcc-wrap + +7. Now do + +   make clean +   make + + This will re-compile the kernel, but this time retaining the + preprocessed source files. + +8. You can now compile the preprocessed source files with goto-cc as + follows: + + find ./ -name .tmp_*.i > source-file-list + for a in `cat source-file-list` ; do +   goto-cc -c $a -o $a.gb + done + + Note that it is important that the word-size of the kernel + configuration matches that of goto-cc. Otherwise, compile-time + assertions will fail, generating the error message "bit field size + is negative". For a kernel configured for a 64-bit word-width, pass + the option --64 to goto-cc. + +The resulting `.gb` files can be passed to any of the CPROVER tools. + +\subsection man_goto-cc-apache goto-cc: Extracting Models from the Apache HTTPD + +The [Apache HTTPD](http://httpd.apache.org/) is still the most +frequently used web server. Together with the relevant libraries, it +consists of around 0.4 million lines of C code. In the following, we +show how to extract models from Apache HTTPD 2.4.2. + +1. First of all, we download the sources of Apache HTTPD and two + supporting libraries and uncompress them: + + lwp-download http://www.mirrorservice.org/sites/ftp.apache.org/apr/apr-1.4.6.tar.bz2 + lwp-download http://www.mirrorservice.org/sites/ftp.apache.org/apr/apr-util-1.4.1.tar.bz2 + lwp-download http://mirror.catn.com/pub/apache/httpd/httpd-2.4.2.tar.bz2 + bunzip2 < apr-1.4.6.tar.bz2 | tar x + bunzip2 < apr-util-1.4.1.tar.bz2 | tar x + bunzip2 < httpd-2.4.2.tar.bz2 | tar x + +2. Now compile [gcc-wrap.c](gcc-wrap.c) and put the resulting binary + into a directory that is in your PATH variable: + + lwp-download http://www.cprover.org/cprover-manual/gcc-wrap.c + gcc gcc-wrap.c -o gcc-wrap + cp gcc-wrap ~/bin/ + + This assumes that the directory `~/bin` exists and is in your + PATH variable. + +3. We now build the sources with gcc: + + (cd apr-1.4.6; ./configure; make CC=gcc-wrap) + (cd apr-util-1.4.1; ./configure --with-apr=../apr-1.4.6 ; make CC=gcc-wrap) + (cd httpd-2.4.2; ./configure --with-apr=../apr-1.4.6 --with-apr-util=../apr-util-1.4.1 ; make CC=gcc-wrap) + +4. You can now compile the preprocessed source files with goto-cc as + follows: + + find ./ -name *.i > source-file-list + for a in `cat source-file-list` ; do +   goto-cc -c $a -o $a.gb + done + +The resulting `.gb` files can be passed to any of the CPROVER tools. diff --git a/doc/html-manual/api.shtml b/doc/html-manual/api.shtml deleted file mode 100644 index 77b7edc1ae..0000000000 --- a/doc/html-manual/api.shtml +++ /dev/null @@ -1,323 +0,0 @@ - - -

CPROVER Manual TOC

- -

The CPROVER API Reference

- -

-The following sections summarize the functions available to programs -that are passed to the CPROVER tools. -

- -

Functions

- -

__CPROVER_assume, __CPROVER_assert, assert

- -
- -void __CPROVER_assume(_Bool assumption);
-void __CPROVER_assert(_Bool assertion, const char *description);
-void assert(_Bool assertion); - -
- -

-The function __CPROVER_assume adds an expression as a constraint -to the program. If the expression evaluates to false, the execution -aborts without failure. More detail on the use of assumptions is -in the section on Assumptions -and Assertions. -

- -

__CPROVER_same_object, __CPROVER_POINTER_OBJECT, -__CPROVER_POINTER_OFFSET, -__CPROVER_DYNAMIC_OBJECT

- -
- -_Bool __CPROVER_same_object(const void *, const void *);
-unsigned __CPROVER_POINTER_OBJECT(const void *p);
-signed __CPROVER_POINTER_OFFSET(const void *p);
-_Bool __CPROVER_DYNAMIC_OBJECT(const void *p); - -
- -

-The function __CPROVER_same_object returns true -if the two pointers given as arguments point to the same -object. -The function __CPROVER_POINTER_OFFSET returns -the offset of the given pointer relative to the base -address of the object. -The function __CPROVER_DYNAMIC_OBJECT -returns true if the pointer passed -as arguments points to a dynamically allocated object. -

- -

__CPROVER_is_zero_string, -__CPROVER_zero_string_length, -__CPROVER_buffer_size

- -
- -_Bool __CPROVER_is_zero_string(const void *);
-__CPROVER_size_t __CPROVER_zero_string_length(const void *);
-__CPROVER_size_t __CPROVER_buffer_size(const void *); - -
- -

-

- -

__CPROVER_initialize

- -
- -void __CPROVER_initialize(void); - -
- -

-The function __CPROVER_initialize computes the initial -state of the program. It is called prior to calling the -main procedure of the program. -

- -

__CPROVER_input, __CPROVER_output

- -
- -void __CPROVER_input(const char *id, ...);
-void __CPROVER_output(const char *id, ...); - -
- -

-The functions __CPROVER_input and __CPROVER_output -are used to report an input or output value. Note that they do not generate -input or output values. The first argument is a string constant -to distinguish multiple inputs and outputs (inputs are typically -generated using nondeterminism, as described -here). -The string constant is followed by an arbitrary number of values of -arbitrary types. -

- -

__CPROVER_cover

- -
- -void __CPROVER_cover(_Bool condition); - -
- -

This statement defines a custom coverage criterion, for usage -with the test suite generation feature.

- -

-

- -

__CPROVER_isnan, __CPROVER_isfinite, __CPROVER_isinf, -__CPROVER_isnormal, __CPROVER_sign

- -
- -_Bool __CPROVER_isnan(double f);
-_Bool __CPROVER_isfinite(double f);
-_Bool __CPROVER_isinf(double f);
-_Bool __CPROVER_isnormal(double f);
-_Bool __CPROVER_sign(double f); - -
- -

-The function __CPROVER_isnan returns true if the double-precision -floating-point number passed as argument is a -NaN. -

- -

-The function __CPROVER_isfinite returns true if the double-precision -floating-point number passed as argument is a -finite number. -

- -

-This function __CPROVER_isinf returns true if the double-precision -floating-point number passed as argument is plus -or minus infinity. -

- -

-The function __CPROVER_isnormal returns true if the double-precision -floating-point number passed as argument is a -normal number. -

- -

-This function __CPROVER_sign returns true if the double-precision -floating-point number passed as argument is -negative. -

- -

__CPROVER_abs, __CPROVER_labs, __CPROVER_fabs, __CPROVER_fabsl, __CPROVER_fabsf

- -
- -int __CPROVER_abs(int x);
-long int __CPROVER_labs(long int x);
-double __CPROVER_fabs(double x);
-long double __CPROVER_fabsl(long double x);
-float __CPROVER_fabsf(float x); - -
- -

-These functions return the absolute value of the given -argument. -

- -

__CPROVER_array_equal, __CPROVER_array_copy, __CPROVER_array_set

- -
- -_Bool __CPROVER_array_equal(const void array1[], const void array2[]);
-void __CPROVER_array_copy(const void dest[], const void src[]);
-void __CPROVER_array_set(const void dest[], value); - -
- -

-The function __CPROVER_array_equal returns true if the values -stored in the given arrays are equal. -The function __CPROVER_array_copy copies the contents of -the array src to the array dest. -The function __CPROVER_array_set initializes the array dest with -the given value. -

- -

Uninterpreted Functions

- -

-Uninterpreted functions are documented here. -

- -

Predefined Types and Symbols

- -

__CPROVER_bitvector

- -
- -__CPROVER_bitvector [ expression ] - -
- -

-This type is only available in the C frontend. It is used -to specify a bit vector with arbitrary but fixed size. The -usual integer type modifiers signed and unsigned -can be applied. The usual arithmetic promotions will be -applied to operands of this type. -

- -

__CPROVER_floatbv

- -
- -__CPROVER_floatbv [ expression ] [ expression ] - -
- -

-This type is only available in the C frontend. It is used -to specify an IEEE-754 floating point number with arbitrary -but fixed size. The first parameter is the total size (in bits) -of the number, and the second is the size (in bits) of the -mantissa, or significand (not including the hidden bit, thus for -single precision this should be 23). -

- -

__CPROVER_fixedbv

- -
- -__CPROVER_fixedbv [ expression ] [ expression ] - -
- -

-This type is only available in the C frontend. It is used -to specify a fixed-point bit vector with arbitrary -but fixed size. The first parameter is the total size (in bits) -of the type, and the second is the number of bits after the radix -point. -

- -

__CPROVER_size_t

- -

-The type of sizeof expressions. -

- -

__CPROVER_rounding_mode

- -
- -extern int __CPROVER_rounding_mode; - -
- -

-This variable contains the IEEE floating-point -arithmetic rounding mode. -

- -

__CPROVER_constant_infinity_uint

- -

-This is a constant that models a large unsigned -integer. -

- -

__CPROVER_integer, __CPROVER_rational

- -

-__CPROVER_integer is an unbounded, signed integer type. -__CPROVER_rational is an unbounded, signed rational -number type. -

- -

__CPROVER_memory

- -
- -extern unsigned char __CPROVER_memory[]; - -
- -

-This array models the contents of integer-addressed memory. -

- -

__CPROVER::unsignedbv<N> (C++ only)

- -

This type is the equivalent of unsigned __CPROVER_bitvector[N] in the C++ front-end. -

- -

__CPROVER::signedbv<N> (C++ only)

- -

This type is the equivalent of signed __CPROVER_bitvector[N] in the C++ front-end. -

- -

__CPROVER::fixedbv<N> (C++ only)

- -

This type is the equivalent of __CPROVER_fixedbv[N,m] in the C++ front-end. -

- -

Concurrency

- -

-Asynchronous threads are created by preceding an instruction with a label with the prefix __CPROVER_ASYNC_. -

- - diff --git a/doc/html-manual/architecture.shtml b/doc/html-manual/architecture.shtml deleted file mode 100644 index 18ef3e0b1f..0000000000 --- a/doc/html-manual/architecture.shtml +++ /dev/null @@ -1,93 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Architectural Settings

- -

The behavior of a C/C++ program depends on a number of -parameters that are specific to the architecture the program was compiled -for. The three most important architectural parameters are:

- -
    -
  • The width of the various scalar types; e.g., compare the value -of sizeof(long int) on various machines.
    • - -
  • The width of pointers; e.g., compare the value -of sizeof(int *) on various machines.
    • - -
  • The endianness -of the architecture.
    • -
- -

-In general, the CPROVER tools attempt to adopt the settings of the -particular architecture the tool itself was compiled for. For example, -when running a 64 bit binary of CBMC on Linux, the program will be processed -assuming that sizeof(long int)==8.

- -

-As a consequence of these architectural parameters, -you may observe different verification results for an identical -program when running CBMC on different machines. In order to get -consistent results, or when aiming at validating a program written -for a different platform, the following command-line arguments can -be passed to the CPROVER tools:

- -
    -
  • The word-width can be set with --16, ---32, --64.
    • -
  • The endianness can be defined with ---little-endian and --big-endian.
    • -
- -

-When using a goto binary, CBMC and the other tools read the configuration -from the binary, i.e., the setting when running goto-cc is the one that -matters; the option given to the model checker is ignored in this case. -

- -

-In order to see the effect of the options --16, ---32 and --64, pass -the following program to CBMC:

- -
- -#include <stdio.h>
-#include <assert.h>
-
-int main() {
-  printf("sizeof(long int): %d\n", (int)sizeof(long int));
-  printf("sizeof(int *): %d\n", (int)sizeof(int *));
-  assert(0);
-} - -
- -

-The counterexample trace contains the strings printed by the -printf command.

- -

-The effects of endianness are -more subtle. Try the following program with --big-endian -and --little-endian:

- -
-

-#include <stdio.h>

-#include <assert.h>

-

-int main() {

-  int i=0x01020304;

-  char *p=(char *)&i;

-  printf("Bytes of i: %d, %d, %d, %d\n",

-         p[0], p[1], p[2], p[3]);

-  assert(0);

-}
-
-
- - diff --git a/doc/html-manual/cbmc-loops.shtml b/doc/html-manual/cbmc-loops.shtml deleted file mode 100644 index da4df1eaee..0000000000 --- a/doc/html-manual/cbmc-loops.shtml +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - -

CPROVER Manual TOC

- -

CBMC: Bounded Model Checking for C/C++ and Java

- -

Understanding Loop Unwinding

- -

Iteration-based Unwinding

- -

-The basic idea of CBMC is to model the computation of the programs up to a -particular depth. Technically, this is achieved by a process that -essentially amounts to unwinding loops. This concept is best -illustrated with a generic example: -

- -
int main(int argc, char **argv) {
-  while(cond) {
-    BODY CODE
-  }
-}
-
- -

-A BMC instance that will find bugs with up to five iterations of the loop would -contain five copies of the loop body, and essentially corresponds to checking -the following loop-free program: -

- -
int main(int argc, char **argv) {
-  if(cond) {
-    BODY CODE COPY 1
-    if(cond) {
-      BODY CODE COPY 2
-      if(cond) {
-        BODY CODE COPY 3
-        if(cond) {
-          BODY CODE COPY 4
-          if(cond) {
-            BODY CODE COPY 5
-          }
-        }
-      }
-    }
-  }
-}
-
- -

-Note the use of the if statement to prevent the execution of -the loop body in the case that the loop ends before five iterations are executed. -The construction above is meant to produce a program that is trace equivalent -with the original programs for those traces that contain up to five iterations -of the loop. -

- -

-In many cases, CBMC is able to automatically determine an upper bound on the - -number of loop iterations. This may even work when the number of loop -unwindings is not constant. Consider the following example: -

- -
_Bool f();
-
-int main() {
-  for(int i=0; i<100; i++) {
-    if(f()) break;
-  }
-  
-  assert(0);
-}
-
- -

-The loop in the program above has an obvious upper bound on the number of -iterations, but note that the loop may abort prematurely depending on the -value that is returned by f(). CBMC is nevertheless able to -automatically unwind the loop to completion.

- -

-This automatic detection of the unwinding -bound may fail if the number of loop iterations is highly data-dependent. -Furthermore, the number of iterations that are executed by any given -loop may be too large or may simply be unbounded. For this case, -CBMC offers the command-line option --unwind B, where -B denotes a number that corresponds to the maximal number -of loop unwindings CBMC performs on any loop. -

- -

-Note that the number of unwindings is measured by counting the number of -backjumps. In the example above, note that the condition -i<100 is in fact evaluated 101 times before the loop -terminates. Thus, the loop requires a limit of 101, and not 100.

- -

Setting Separate Unwinding Limits

- -

-The setting given with --unwind is used globally, -that is, for all loops in the program. In order to set individual -limits for the loops, first use -

- - -  --show-loops - - -

-to obtain a list of all loops in the program. Then identify the loops -you need to set a separate bound for, and note their loop ID. Then -use -

- - -  --unwindset L:B,L:B,... - - -

-where L denotes a loop ID and B denotes -the bound for that loop.

- -

-As an example, consider a program with two loops in the function -main: -

- - -  --unwindset c::main.0:10,c::main.1:20 - - -

-This sets a bound of 10 for the first loop, and a bound of 20 for -the second loop. -

- -

-What if the number of unwindings specified is too small? In this case, bugs -that require paths that are deeper may be missed. In order to address this -problem, CBMC can optionally insert checks that the given unwinding bound is -actually sufficiently large. These checks are called unwinding -assertions, and are enabled with the option ---unwinding-assertions. Continuing the generic example above, -this unwinding assertion for a bound of five corresponds to checking the -following loop-free program: -

- -
int main(int argc, char **argv) {
-  if(cond) {
-    BODY CODE COPY 1
-    if(cond) {
-      BODY CODE COPY 2
-      if(cond) {
-        BODY CODE COPY 3
-        if(cond) {
-          BODY CODE COPY 4
-          if(cond) {
-            BODY CODE COPY 5
-            assert(!cond);
-          }
-        }
-      }
-    }
-  }
-}
-
- -

-The unwinding assertions can be verified just like any other generated -assertion. If all of them are proven to hold, the given loop bounds are -sufficient for the program. This establishes a high-level -worst-case execution time (WCET). -

- -

-In some cases, it is desirable to cut off very deep loops in favor -of code that follows the loop. As an example, consider the -following program: -

- -
int main() {
-  for(int i=0; i<10000; i++) {
-    BODY CODE
-  }
-  
-  assert(0);
-}
-
- -

-In the example above, small values of --unwind will -prevent that the assertion is reached. If the code in the loop -is considered irrelevant to the later assertion, use the option -

- - -  --partial-loops - - -

-This option will allow paths that execute loops only partially, -enabling a counterexample for the assertion above even for -small unwinding bounds. The disadvantage of using this option -is that the resulting path may be spurious, i.e., may not -exist in the original program. -

- -

Depth-based Unwinding

- -

-The loop-based unwinding bound is not always appropriate. In particular, -it is often difficult to control the size of the generated formula -when using the --unwind option. The option -

- - -  --depth nr - - -

-specifies an unwinding bound in terms of the number of instructions that are -executed on a given path, irrespectively of the number of loop iterations. -Note that CBMC uses the number of instructions in the control-flow graph -as the criterion, not the number of instructions in the source code. -

- - diff --git a/doc/html-manual/cbmc.shtml b/doc/html-manual/cbmc.shtml deleted file mode 100644 index a52f39a90f..0000000000 --- a/doc/html-manual/cbmc.shtml +++ /dev/null @@ -1,377 +0,0 @@ - - - - - - -

CPROVER Manual TOC

- -

CBMC: Bounded Model Checking for C/C++ and Java

- -

A Short Tutorial

- -

First Steps

- -

-We assume you have already installed CBMC and the necessary support files -on your system. If not so, please follow -these instructions. -

- -

-Like a compiler, CBMC takes the names of .c files as command line -arguments. CBMC then translates the program and merges the function -definitions from the various .c files, just like a linker. But instead -of producing a binary for execution, CBMC performs symbolic simulation on -the program. -

- -

-As an example, consider the following simple program, named -file1.c: -

- -
int puts(const char *s) { }
-
-int main(int argc, char **argv) {
-  puts(argv[2]);
-}
-
- -

-Of course, this program is faulty, as the argv array might have fewer -than three elements, and then the array access argv[2] is out of bounds. -Now, run CBMC as follows: -

- - -  cbmc file1.c --show-properties --bounds-check --pointer-check - - -

The two options --bounds-check and --pointer-check -instruct CBMC to look for errors related to pointers and array bounds. -CBMC will print the list of properties it checks. Note that it lists, -among others, a property labeled with "object bounds in argv" together with -the location of the faulty array access. As you can see, CBMC largely -determines the property it needs to check itself. This is realized by means -of a preliminary static analysis, which relies on computing a fixed point on -various abstract -domains. More detail on automatically generated properties is provided -here.

- -

-Note that these automatically generated properties need not necessarily -correspond to bugs – these are just potential flaws, as -abstract interpretation might be imprecise. Whether these properties -hold or correspond to actual bugs needs to be determined by further analysis. -

- -

-CBMC performs this analysis using symbolic simulation, which -corresponds to a translation of the program into a formula. The formula is -then combined with the property. Let's look at the formula that is -generated by CBMC's symbolic simulation:

- - -  cbmc file1.c --show-vcc --bounds-check --pointer-check - - -

-With this option, CBMC performs the symbolic simulation and prints the -verification conditions on the screen. A verification condition needs -to be proven to be valid by a -decision procedure in order to assert that the corresponding property -holds. Let's run the decision procedure:

- - -  cbmc file1.c --bounds-check --pointer-check - - -

-CBMC transforms the equation you have seen before into CNF and passes it to -a SAT solver (more background on this step is in the book on Decision Procedures). It -then determines which of the properties that it has generated for the -program hold and which do not. Using the SAT solver, CBMC detects that the -property for the object bounds of argv does not hold, and will -thus print a line as follows: -

- - -[main.pointer_dereference.6] dereference failure: object bounds in argv[(signed long int)2]: FAILURE - - -

Counterexample Traces

- -

-Let us have a closer look at this property and why it fails. To aid the -understanding of the problem, CBMC can generate a counterexample -trace for failed properties. To obtain this trace, run -

- - -  cbmc file1.c --bounds-check --trace - - -

-CBMC then prints a counterexample trace, i.e., a program trace that begins -with main and ends in a state which violates the property. In -our example, the program trace ends in the faulty array access. It also -gives the values the input variables must have for the bug to occur. In -this example, argc must be one to trigger the out-of-bounds -array access. If you add a branch to the example that requires that -argc>=3, the bug is fixed and CBMC will report that the -proofs of all properties have been successful.

- -

Verifying Modules

- -

-In the example above, we used a program that starts with a main -function. However, CBMC is aimed at embedded software, and these -kinds of programs usually have different entry points. Furthermore, CBMC -is also useful for verifying program modules. Consider the following example, -called file2.c: -

- -
int array[10];
-int sum() {
-  unsigned i, sum;
-
-  sum=0;
-  for(i=0; i<10; i++)
-    sum+=array[i];
-}
-
- -

-In order to set the entry point to the sum function, run -

- - -  cbmc file2.c --function sum --bounds-check - - -

-It is often necessary to build a suitable harness for the function -in order to set up the environment appropriately. -

- -

Loop Unwinding

- -

-When running the previous example, you will have noted that CBMC unwinds the -for loop in the program. As CBMC performs Bounded Model -Checking, all loops have to have a finite upper run-time bound in order to -guarantee that all bugs are found. CBMC can optionally check that enough -unwinding is performed. As an example, consider the program binsearch.c: -

- -
int binsearch(int x) {
-  int a[16];
-  signed low=0, high=16;
-
-  while(low<high) {
-    signed middle=low+((high-low)>>1);
-
-    if(a[middle]<x)
-      high=middle;
-    else if(a[middle]>x)
-      low=middle+1;
-    else // a[middle]==x
-      return middle;
-  }
-
-  return -1;
-}
-
- -

-If you run CBMC on this function, you will notice that the unwinding -does not stop on its own. The built-in simplifier is not able to determine -a run time bound for this loop. The unwinding bound has to be given as a -command line argument:

- - -  cbmc binsearch.c --function binsearch --unwind 6 --bounds-check --unwinding-assertions - - -

-CBMC verifies that verifies the array accesses are within the bounds; note -that this actually depends on the result of the right shift. In addition, -as CBMC is given the option ---unwinding-assertions, it also checks that enough -unwinding is done, i.e., it proves a run-time bound. For any lower -unwinding bound, there are traces that require more loop iterations. Thus, -CBMC will report that the unwinding assertion has failed. As usual, a counterexample -trace that documents this can be obtained with the option ---property. -

- -

Unbounded Loops

- -

-CBMC can also be used for programs with unbounded loops. In this -case, CBMC is used for bug hunting only; CBMC does not attempt to find -all bugs. The following program -(lock-example.c) is an example -of a program with a user-specified property:

- -
_Bool nondet_bool();
-_Bool LOCK = 0;
-
-_Bool lock() {
-  if(nondet_bool()) {
-    assert(!LOCK);
-    LOCK=1;
-    return 1; }
-
-  return 0;
-}
-
-void unlock() {
-  assert(LOCK);
-  LOCK=0;
-}
-
-int main() {
-  unsigned got_lock = 0;
-  int times;
-
-  while(times > 0) {
-    if(lock()) {
-      got_lock++;
-      /* critical section */
-    }
-
-    if(got_lock!=0)
-      unlock();
-
-    got_lock--;
-    times--;
-} }
-
- -

-The while loop in the main function has no -(useful) run-time bound. Thus, a bound has to be set on the amount of -unwinding that CBMC performs. There are two ways to do so: -

- -
    - -
  1. The --unwind command-line parameter can to be used to limit -the number of times loops are unwound.
    2. - -
  2. The --depth command-line parameter can be used to limit -the number of program steps to be processed.
    3. - -
- -

-Given the option --unwinding-assertions, CBMC checks whether -the arugment to --unwind is large enough to cover all program -paths. If the argument is too small, CBMC will detect that not enough -unwinding is done reports that an unwinding assertion has failed. -

- -

-Reconsider the example. For a loop unwinding bound of one, no bug is found. -But already for a bound of two, CBMC detects a trace that violates an -assertion. Without unwinding assertions, or when using the --depth -command line switch, CBMC does not prove the program correct, but it can be -helpful to find program bugs. The various command line options that CBMC -offers for loop unwinding are described in the section on -understanding loop unwinding.

- -

A Note About Compilers and the ANSI-C Library

- -

-Most C programs make use of functions provided by a library; instances are -functions from the standard ANSI-C library such as malloc or -printf. The verification of programs that use such functions -has two requirements:

- -
    - -
  1. Appropriate header files have to be provided. These header files -contain declarations of the functions that are to be used. -
    2. - -
  2. Appropriate definitions have to be provided.
    3. - -
- -

-Most C compilers come with header files for the ANSI-C library functions. -We briefly discuss how to obtain/install these library files. -

- -

Linux

- -

-Linux systems that are able to compile software are usually equipped with -the appropriate header files. Consult the documentation of your distribution -on how to install the compiler and the header files. First try to compile -some significant program before attempting to verify it. -

- -

Windows

- -

-On Microsoft Windows, CBMC is pre-configured to use the compiler that is -part of Microsoft's Visual Studio. Microsoft's -Visual Studio Community is fully featured and available for download for -free from the Microsoft webpage. Visual Studio installs the usual set of -header files together with the compiler. However, the Visual Studio -compiler requires a large set of environment variables to function -correctly. It is therefore required to run CBMC from the Visual Studio -Command Prompt, which can be found in the menu Visual Studio -Tools. -

- -

-Note that in both cases, only header files are available. CBMC only -comes with a small set of definitions, which includes functions such as -malloc. Detailed information about the built-in definitions is -here.

- -

Command Line Interface

- -

-This section describes the command line interface of CBMC. Like a C -compiler, CBMC takes the names of the .c source files as arguments. -Additional options allow to customize the behavior of CBMC. Use -cbmc --help to get a full list of the available options. -

- -

-Structured output can be obtained from CBMC using the option --xml-ui. -Any output from CBMC (e.g., counterexamples) will then use an XML -representation. -

- -
-
Further Reading
- - - -

-We also have a list of -interesting applications of CBMC.

- -
- - - diff --git a/doc/html-manual/counter.v b/doc/html-manual/counter.v deleted file mode 100644 index 4920568889..0000000000 --- a/doc/html-manual/counter.v +++ /dev/null @@ -1,10 +0,0 @@ -module top(input clk); - - reg [3:0] counter; - - initial counter=0; - - always @(posedge clk) - counter=counter+1; - -endmodule diff --git a/doc/html-manual/cover.shtml b/doc/html-manual/cover.shtml deleted file mode 100644 index 3665121f0b..0000000000 --- a/doc/html-manual/cover.shtml +++ /dev/null @@ -1,276 +0,0 @@ - - - - - - -

CPROVER Manual TOC

- -

Automatic Test Suite Generation with CBMC

- -

A Small Tutorial with A Case Study

- -

-We assume that CBMC is installed on your system. If not so, follow -these instructions.

- -

-CBMC can be used to automatically generate test cases that satisfy a certain code coverage -criterion. Common coverage criteria include branch coverage, condition -coverage and Modified -Condition/Decision Coverage (MC/DC). Among others, MC/DC is required -by several avionics software development guidelines to ensure adequate testing -of safety critical software. Briefly, in order to satisfy MC/DC, -for every conditional statement containing boolean decisions, each Boolean -variable should be evaluated one time to "true" and one time to "false", -in a way that affects the outcome of the decision. -

- -

-In the following, we are going to demonstrate how to apply the test suite -generation functionality in CBMC, by means of a case study. The program -pid.c is an excerpt from a real-time embedded benchmark PapaBench, -and implements part of a fly-by-wire autopilot for an Unmanned Aerial Vehicle (UAV). -It is adjusted mildly for our purposes. -

- -

-The aim of function climb_pid_run is to control the vertical climb of the UAV. -Details on the theory behind this operation are documented in the wiki for the Paparazzi UAV project. -The behaviour of this simple controller, supposing that the desired speed is 0.5 meters per second, -is plotted in the Figure below. -

- -
- -The pid controller - -
- -
01: // CONSTANTS:
-02: #define MAX_CLIMB_SUM_ERR 10
-03: #define MAX_CLIMB 1
-04:
-05: #define CLOCK 16
-06: #define MAX_PPRZ (CLOCK*600)
-07:
-08: #define CLIMB_LEVEL_GAZ 0.31
-09: #define CLIMB_GAZ_OF_CLIMB 0.75
-10: #define CLIMB_PITCH_OF_VZ_PGAIN 0.05
-11: #define CLIMB_PGAIN -0.03
-12: #define CLIMB_IGAIN 0.1
-13:
-14: const float pitch_of_vz_pgain=CLIMB_PITCH_OF_VZ_PGAIN;
-15: const float climb_pgain=CLIMB_PGAIN;
-16: const float climb_igain=CLIMB_IGAIN;
-17: const float nav_pitch=0;
-18:
-19: /** PID function INPUTS */
-20: // The user input: target speed in vertical direction
-21: float desired_climb;
-22: // Vertical speed of the UAV detected by GPS sensor
-23: float estimator_z_dot;
-24:
-25: /** PID function OUTPUTS */
-26: float desired_gaz;
-27: float desired_pitch;
-28:
-29: /** The state variable: accumulated error in the control */
-30: float climb_sum_err=0;
-31:
-32: /** Computes desired_gaz and desired_pitch */
-33: void climb_pid_run() 
-34: {
-35:
-36:   float err=estimator_z_dot-desired_climb;
-37:
-38:   float fgaz=climb_pgain*(err+climb_igain*climb_sum_err)+CLIMB_LEVEL_GAZ+CLIMB_GAZ_OF_CLIMB*desired_climb;
-39:
-40:   float pprz=fgaz*MAX_PPRZ;
-41:   desired_gaz=((pprz>=0 && pprz<=MAX_PPRZ) ? pprz : (pprz>MAX_PPRZ ? MAX_PPRZ : 0));
-42:
-43:   /** pitch offset for climb */
-44:   float pitch_of_vz=(desired_climb>0) ? desired_climb*pitch_of_vz_pgain : 0;
-45:   desired_pitch=nav_pitch+pitch_of_vz;
-46:
-47:   climb_sum_err=err+climb_sum_err;
-48:   if (climb_sum_err>MAX_CLIMB_SUM_ERR) climb_sum_err=MAX_CLIMB_SUM_ERR;
-49:   if (climb_sum_err<-MAX_CLIMB_SUM_ERR) climb_sum_err=-MAX_CLIMB_SUM_ERR;
-50:
-51: }
-52:
-53: int main()
-54: {
-55:
-56:   while(1)
-57:   {
-58:     /** Non-deterministic input values */ 
-59:     desired_climb=nondet_float();
-60:     estimator_z_dot=nondet_float();
-61:
-62:     /** Range of input values */ 
-63:     __CPROVER_assume(desired_climb>=-MAX_CLIMB && desired_climb<=MAX_CLIMB);
-64:     __CPROVER_assume(estimator_z_dot>=-MAX_CLIMB && estimator_z_dot<=MAX_CLIMB);
-65:
-66:     __CPROVER_input("desired_climb", desired_climb);
-67:     __CPROVER_input("estimator_z_dot", estimator_z_dot);
-68:
-69:     climb_pid_run();
-70:
-71:     __CPROVER_output("desired_gaz", desired_gaz);
-72:     __CPROVER_output("desired_pitch", desired_pitch);
-73:
-74:   }
-75:
-76:   return 0;
-77: }
-
- -

-In order to test the PID controller, we construct a main control loop, -which repeatedly invokes the function climb_pid_run (line 69). -This PID function has two input variables: the desired speed desired_climb -and the estimated speed estimated_z_dot. -In the beginning of each loop iteration, values of the inputs are assigned non-deterministically. -Subsequently, the __CPROVER_assume statement in lines 63 and 64 guarantees that -both values are bounded within a valid range. -The __CPROVER_input and __CPROVER_output will help clarify the inputs -and outputs of interest for generating test suites. -

- -

-To demonstrate the automatic test suite generation in CBMC, -we call the following command and we are going to explain the command line options one by one. -

- -
cbmc pid.c --cover mcdc --unwind 6 --xml-ui
-
- -

-The option --cover mcdc specifies the code coverage criterion. -There are four conditional statements in the PID function: in line 41, line 44, -line 48 and line 49. -To satisfy MC/DC, the test suite has to meet multiple requirements. -For instance, each conditional statement needs to evaluate to true and false. -Consider the condition "pprz>=0 && pprz<=MAX_PPRZ" in line 41. CBMC -instruments three coverage goals to control the respective evaluated results of "pprz>=0" and -"pprz<=MAX_PPRZ". -We list them in below and they satisfy the MC/DC rules. -Note that MAX_PPRZ is defined as 16 * 600 in line 06 of the program. -

- -
-!(pprz >= (float)0) && pprz <= (float)(16 * 600)  id="climb_pid_run.coverage.1"
-pprz >= (float)0 && !(pprz <= (float)(16 * 600))  id="climb_pid_run.coverage.2"
-pprz >= (float)0 && pprz <= (float)(16 * 600)     id="climb_pid_run.coverage.3"
-
- -

-The "id" of each coverage goal is automatically assigned by CBMC. For every -coverage goal, a test suite (if there exists) that -satisfies such a goal is printed out in XML format, as the parameter ---xml-ui is given. Multiple coverage goals can share a -test suite, when the corresponding execution of the program satisfies all these -goals at the same time. -

- -

-In the end, the following test suites are automatically generated for testing the PID controller. -A test suite consists of a sequence of input parameters that are -passed to the PID function climb_pid_run at each loop iteration. -For example, Test 1 covers the MC/DC goal with id="climb_pid_run.coverage.1". -The complete output from CBMC is in -pid_test_suites.xml, where every test suite and the coverage goals it is for -are clearly described. - -

Test suite:
-Test 1. 
-  (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-
-Test 2.
-  (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f 
-  (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f 
-
-Test 3.
-  (iteration 1) desired_climb=0.000000f, estimator_z_dot=-1.000000f
-  (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-
-Test 4.
-  (iteration 1) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-  (iteration 2) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-  (iteration 3) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-  (iteration 4) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-  (iteration 5) desired_climb=0.000000f, estimator_z_dot=-1.000000f
-  (iteration 6) desired_climb=1.000000f, estimator_z_dot=-1.000000f
-
-Test 5.
-  (iteration 1) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-  (iteration 2) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-  (iteration 3) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-  (iteration 4) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-  (iteration 5) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-  (iteration 6) desired_climb=-1.000000f, estimator_z_dot=1.000000f
-
- -

-The option --unwind 6 unwinds the loop inside the main -function body six times. In order to achieve the complete coverage on all the instrumented goals -in the PID function climb_pid_run, the loop must be unwound sufficient enough times. -For example, climb_pid_run needs to be called at least six times for evaluating the -condition climb_sum_err>MAX_CLIMB_SUM_ERR in line 48 to true. -This corresponds to the Test 5. -An introduction to the use of loop unwinding can be found -in Understanding Loop Unwinding. -

- -

-In this small tutorial, we present the automatic test suite generation -functionality of CBMC, by applying the MC/DC code coverage criterion to a -PID controller case study. In addition to --cover mcdc, other -coverage criteria like branch, decision, -path etc. are also available when calling CBMC. -

- -

Coverage Criteria

- -

-The table below summarizes the coverage criteria that CBMC supports. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CriterionDefinition
assertionFor every assertion, generate a test that reaches it
locationFor every location, generate a test that reaches it
branchGenerate a test for every branch outcome
decisionGenerate a test for both outcomes of every Boolean expression -that is not an operand of a propositional connective
conditionGenerate a test for both outcomes of every Boolean expression
mcdcModified Condition/Decision Coverage (MC/DC)
pathBounded path coverage
coverGenerate a test for every __CPROVER_cover statement -
- - diff --git a/doc/html-manual/cprover-source.shtml b/doc/html-manual/cprover-source.shtml deleted file mode 100644 index 29f273ceea..0000000000 --- a/doc/html-manual/cprover-source.shtml +++ /dev/null @@ -1,877 +0,0 @@ - - - - - - -

CPROVER Manual TOC

- -

The CPROVER Source Code Reference

- -

-The following sections provide an introduction for anybody who -wishes to modify CBMC or build new tools on top of the APIs used -by CBMC. They summarize key components, data structures and APIs -that are used to build the CPROVER tools. -

- -

Source Code Availability and Compilation

- -

-The most recent source code of CBMC and the CPROVER infrastructure can be obtained -via git at https://github.com/diffblue/cbmc.git. -Tar balls for releases are available at https://github.com/diffblue/cbmc/releases. -

- -

-Detailed instructions on how to build CBMC from source are given -in the file COMPILING. -

- -

Components

- -
-
From C source code file to CPROVER's IR
- -

-The sources of the C frontend are located in the "src/ansi-c" directory. It -uses a standard Flex/Bison setup for scanning and parsing the files. The -Flex scanner produces a token sequence, which is turned into a tree -representation of the input program using the Bison grammar. The -typechecker subsequently annotates this parse tree with types and generates -a symbol table. The symbol table is a map from identifiers (functions, -variables and types) to their definitions. -

- -

-The following example illustrates how to use the frontend for parsing files and -for translating them into a symbol table. A call to parse generates -the parse tree of the program. The conversion into the symbol table is -performed during type checking, which is done by a call to the -typecheck method. The symbol table is a map from identifiers to the -symbolt data structure. -

- -
#include <iostream>
-#include <fstream>
-#include <sstream>
-#include <string>
-
-#include <ansi-c/ansi_c_language.h>
-#include <util/cmdline.h>
-#include <util/config.h>
-
-int main(int argc, const char* argv[])
-{
-   // Command line: parse  -I incl_dir file1 ...
-   cmdlinet cmdl;
-   cmdl.parse(argc, argv, "I:");
-
-   config.init();
-
-   if(cmdl.isset('I'))	
-     config.ansi_c.include_paths=cmdl.get_values('I');
-
-   // Set language to C
-   std::auto_ptr<languaget> clang=new_ansi_c_language();
-
-   // Symbol table
-   symbol_tablet my_symbol_table;
-
-   for(const auto & arg : cmdl.args)
-   {
-     // Source code stream
-     std::ifstream in(arg.c_str());	
-
-     // Parse
-     clang->parse(in, "", std::cerr);
-
-     // Typecheck
-     clang->typecheck(my_symbol_table, arg, std::cerr);
-  }
-
-  // Do some final adjustements
-  clang->final(my_symbol_table, std::cerr);
-
-  my_symbol_table.show(std::cout);
-
-  return 0;
-}
-
- -

-The parse trees are implemented using a class called irept. Its -declaration and definiton can be found in the files "src/util/irep.h" and -"src/util/irep.cpp", respectively. -

- -

-The excerpt below gives some details of the class irept: -

- -
class irept
-{
-public:
-  typedef std::vector<irept> subt;
-  typedef std::map<irep_name_string, irept> named_subt;
-  ...
-
-public:
-  class dt
-  {
-  public:
-    unsigned ref_count;
-    dstring data;
-    named_subt named_sub;
-    named_subt comments;
-    subt sub;
-    ...
-  };
-
-protected:
-  dt *data;
-  ...
-};
-
- -

-Every node of any tree is an object of class irept. Each node has a -pointer to an object of class dt. The dt objects are used -for storing the actual content of nodes. Objects of class dt are -dynamically allocated and can be shared between nodes. A reference-counter -mechanism is implemented to automatically free unreachable dt -objects. A shallow copy of a tree is an O(1) operation. -

- -

-The field data of class dt is a (hashed) string -representing the label of the nodes. The fields named_sub, -comments and sub are links to childs. Edges are either -labeled with a string or ordered. The string-labeled edges are stored in the -map comments if their first character is '#'. Otherwise, they are -stored in the map named_sub. The labels of edges are unique for a -given node; however, their ordering is not preserved. The field sub -is a vector of nodes that is used for storing the ordered children. The order -of edges of this kind is preserved during copy. -

- -
-
Tree for the expression a+b with int a; char -b;.
- -

Interface of Class irept

- -
id
- -
const irep_idt &id();
-void id(const irep_idt &_data);
-
- -

-The first method returns a constant reference to the label of the node. The -second method sets the label of the node. -

- -
is_nil and is_not_nil
- -
virtual bool is_nil() const;
-virtual bool is_not_nil() const;
-
- -

-The first method returns true if the label of the node is equal to "nil". -The second method returns false if the label of the node is equal to "nil". -

- -
find, add and get
- -
const irept &find(const irep_namet &name) const;
-irept &add(const irep_namet &name);
-const irep_idt &get(const irep_namet &name) const;
-
- -
    - -
  1. The first method looks for an edge with label name -and returns the corresponding child. If no edge with label name -is found, then nil_rep is returned.
    2. - -
  2. The second method does the same as the first except that if -no edge with label name if found, then a new child is created -and returned. -
    3. - -
  3. The third method does the same as the first except that the label -of the child is returned (instead of a reference). -If no edge with label name is found, then an empty -string is returned. -
    4. - -
- -
set
- -
void set(const irep_namet &name,
-         const irep_idt &value);
-void set(const irep_namet &name, const long value);
-void set(const irep_namet &name, const irept &irep);
-
- -

-These methods create a new edge with label name. -

- -

-If the second argument is an object of class irept, then it is -assigned to the new child. - -

-If the second argument is a string, then it is set as node-label of the new child. - -

-If the second argument is a number, then it is converted to a -string and set as node-label of the new child. - -

remove
- -
void remove(const irep_namet &name);
-
- -

-This method looks for an edge with label name -and removes it. - -

move_to_sub and move_to_named_sub
- -
void move_to_sub(irept &irep);
-void move_to_named_sub(const irep_namet &name, irept &irep);
-
- -

-The first method creates a new ordered edge with a child equal to -irep. Then it sets irep to nil. The index of the -edge is equal to the size of vector sub before the call. -

- -

-The second method does the same but for labeled edges. -

- -
swap
- -
void swap(irept &irep);
-
- -

-Exchange the content of the invoked node with the one of irep. -

- -
make_nil
- -
void make_nil();
-
- -

-Set the label of the node to "nil" and remove all outgoing edges. -

- -
get_sub and get_named_sub and get_comments
- -
const subt &get_sub();
-const named_subt &get_named_sub();
-const named_subt &get_comments();
-
- -

-Return a constant reference to -sub, named_sub, and comments, respectively. -

- -

Types

- -

-The class typet inherits from irept. Types may have -subtypes. This is modeled with two edges named "subtype" and "subtypes". The -class typet only add specialized methods for accessing the subtype -information to the interface of irept. -

- -

Interface of class typet

- -
has_subtype and has_subtypes
- -
bool has_subtype() const;
-bool has_subtypes() const;
-
- -

-The first method returns true if the a subtype node exists. is not -nil. The second method returns true is a subtypes node exists. -

- -
subtype and subtypes
- -
typet &subtype();
-typest &subtypes();
-
- -

-The first method returns a reference to the 'subtype' node. -The second method returns a reference to the vector of subtypes. -

- -

Subtypes of typet

- -

-A number of subtypes of typet exist which allow convenient -creation and manipulation of typet objects for special types. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ClassDescription
bool_typetBoolean type
symbol_typetSymbol type. Has edge "identifier" to a string value, which can be accessed with get_identifier and set_identifier.
struct_typet, union_typetRepresent a struct, resp. union types. Convenience functions to access components components().
code_typetThe type of a function/procedure. Convenience functions to access arguments() and return_type().
array_typetConvenience function size() to access size of the array.
pointer_typetPointer type, subtype stores the type of the object pointed to.
reference_typetRepresents a reference type, subtype stores the type of the object referenced to.
bv_typetRepresents a bit vector type with variable width.
fixed_bv_typetRepresents a bit vector that encodes a fixed-point number.
floatbv_typetRepresents a bit vector that encodes a floating-point number.
string_typetRepresents a string type.
- -

Source Locations

- -

-The class source_locationt inherits from the class irept. It -is used to store locations in text files. It adds specialized methods to -manipulate the edges named "file", "line", "column", "function". -

- -

Expressions

- -

-The class exprt inherits from class irept. Expressions -have operands and a type. This is modeled with ordered edges for the -operands and an edge labeled"type", respectively. The class exprt -only adds specialized methods for accessing operands and type information -to the interface of irept. -

- -
-
Representation of a binary expression
- -

Interface of class exprt

- -
constructors
- -
explicit exprt(const irep_idt &id);
-
- -

-Creates an exprt object with a given label and no type. -

- -
exprt(const irep_idt &id, const typet &type);
-
- -

-Creates an exprt object with a given label and type. -

- -
type
- -
const typet &type() const;
-typet &type();
-
- -

-Return a reference to the 'type' node -

- -
has_operands
- -
bool has_operands() const;
-
- -

-Return true if the expression has at least one operand. -

- -
operands
- -
const operandst &operands() const;
-
- -

-Return a reference to the vector of operands. -

- -
const exprt &op0();
-const exprt &op1();
-const exprt &op2();
-const exprt &op3();
-exprt &op0();
-exprt &op1();
-exprt &op2();
-exprt &op3();
-
- -

-Return a reference to a specific operand. Avoid calling -if the operand does not exist. -

- -
Constructing common expressions
- -
void make_true();
-void make_false();
-void make_bool(bool value);
-
- -

-Turn the current exprt instance into a expression of type "bool" -with label "constant" and a single edge labeled "value", which points to -a new node with label either "true" or "false". -

- -
void make_typecast(const typet &_type);
-
- -

-Turns the current exprt instance into a typecast. The old value of -the instance is appended as the single operand of the typecast, i.e., the -result is a typecast-expression of the old expression to the indicated type. -

- -
void make_not();
-
- -

-Turns the current exprt instance into an expression with label -"not" of the same type as the original expression. The old value of the -instance is appended as the operand of the "not"-node. If the original -expression is of type "bool", the result represents the negation of the -original expression with the following simplifications possibly applied: -

- -
    -
  • ¬ ¬ f = f
    • -
  • ¬ true = false
    • -
  • ¬ false = true
    • -
- -
-void negate();
-
- -

-Turns the current exprt instance into a negation of itself, depending -on its type: -

- -
    - -
  • For boolean expressions, make_not is called.
    • - -
  • For integers, the current instance is turned into a numeric negation -expression "unary-" of its old value. Chains of "unary-" nodes and -negations of integer constants are simplified.
    • - -
  • For all other types, irept::make_nil is called.
    • - -
- -
bool sum(const exprt &expr);
-bool mul(const exprt &expr);
-bool subtract(const exprt &expr);
-
- -

-Expect the "this" object and the function argument to be constants of the -same numeric type. Turn the current exprt instance into a -constant expression of the same type, whose "value" edge points to the -result of the sum, product, or difference of the two expressions. If the -operation fails for some reason (e.g., the types are different), -true is returned. -

- -
Testing common expressions
- -
bool is_constant() const;
-
- -

-Returns true if the expression label is "constant". -

- -
bool is_boolean() const;
-
- -

-Returns true if the label of the type is "bool". - -

bool is_false() const;
-bool is_true() const;
-
- -

-The first function returns true if the expression is a boolean constant with -value "false". The second function returns true for any boolean constant -that is not of value "false". -

- -
bool is_zero() const;
-bool is_one() const;
-
- -

-The first function returns true if the expression represents a zero numeric -constant, or if the expression represents a null pointer. The second -function returns true if the expression represents a numeric constant with -value "1". -

- -

Subtypes of exprt

- -

-A number of subtypes of exprt provide further convenience functions -for edge access or other specialized behaviour: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ClassDescription
transtRepresents an SMV-style transition system with invariants -invar(), initial state init() and transition -function trans().
true_exprtBoolean constant true expression.
false_exprtBoolean constant false expression.
symbol_exprtRepresents a symbol (e.g., a variable occurrence), convenience function for manipulating "identifier"-edge set_identifier and get_identifier
predicate_exprtConvenience constructors to create expressions of type "bool".
binary_relation_exprt : predicate_exprtConvenience functions to create and manipulate binary expressions of type "bool".
equality_exprt : binary_relation_exprtConvenience functions to create and manipulate equality expressions such as "a == b".
ieee_float_equal_exprt : binary_relation_exprtConvenience functions to create and manipulate equality expressions between floating-point numbers. -
index_exprtRepresents an array access expression such as "a[i]". Convenience functions array() and index() for accessing the array expressions and indexing expression.
typecast_exprtRepresents a cast to the type of the expression.
-and_exprt, -implies_exprt, -or_exprt, -not_exprtRepresentations of logical operators with convenience constructors.
address_of_exprtRepresentation of a C-style &a address-of operation. Convenience function object() for accessing operand.
dereference_exprtRepresentation of a C-style *a pointer-dereference operation. Convenience function object() for accessing operand.
if_exprtRepresentation of a conditional expresion, with convenience functions cond(), true_case() and false_case() for accessing operands.
member_exprtRepresents a some_struct.some_field member access.
codetRepresents a segment of code.
- -

Symbols and the Symbol Table

- -

Symbol

- -

-A symbol is an object of class symbolt. This class -is declared in "util/symbol.h". The code below shows a partial -declaration of the interface: -

- -
class symbolt
-{
-public:
-  typet type;
-  exprt value;
-  std::string name;
-  std::string base_name;
-  ...
-};
-
- -

-Symbol names are unique. Scopes are handled by adding prefixes -to symbols: -

- -
int main(int argc, char* argv[]) {
-	
-	               // Symbol name: c::main::0::alice
-   char alice = 0;     // Symbol base: alice
-   
-   {
-	               // Symbol name: c::main::1::alice
-       int alice = 0;  // Symbol base: alice
-   }
-}
- -

Symbol Table

- -

-A symbol table is an object of class contextt. This class -is declared in "util/context.h". The code below shows a partial -declaration of the interface: -

- -
class symbol_tablett
-{
-public:
-                                 // Insert the symbol
-  bool add(const symbolt &symb);
-                                 // Insert symb into the
-                                 // table and erase it.
-                                 // New_symbol points to the
-                                 // newly inserted element.
-  bool move(symbolt &symbol, symbolt *&new_symbol);
-
-                                 // Insert symb into the
-                                 // table. Then symb is erased.
-  bool move(symbolt &syb);
-
-                                 // Return the entry of the
-                                 // symbol with given name.
-  const irept &value(const std::string &name) const;
-};
-
- -

Goto Programs

- -

-Goto programs are a representation of the control flow graph of a program -that uses only guarded goto and assume statements to model non-sequential -flow. The main definition can be found in -"src/goto-programs/goto_program_template.h", which is a template class. The -concrete instantiation of the template that is used in the framework can be -found in "src/goto-programs/goto_program.h". A single instruction in a goto -program is represented by the class goto_programt::instructiont -whose definition can be found again in -"goto-programs/goto_program_template.h". -

- -

-In the class goto_programt, the control flow graph is represented -as a mixture of sequential transitions between nodes, and non-sequential -transitions at goto-nodes. The sequential flow of the program is captured -by the list instructions that is a field of the class -goto_programt. Transitions via goto statements are represented in -the list targets, which is a field of the class -goto_programt::instructiont, i.e., each goto-instruction carries a -list of possible jump destinations. The latter list targets is a -list of iterators which point to elements of the list instructions. -An illustration is given in the figure below. -

- -
-
Representation of program flow in goto_programt
- -

-Instructions can have a number of different types as represented by -enum goto_program_instruction_typet and can be accessed via the -field type in instructiont. These include: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GOTORepresents a non-deterministic branch to the instructions given in the -list targets. Goto statements are guarded, i.e., the -non-deterministic branch is only taken if the expression in -guard evaluates to true, otherwise the program continues -sequentially. Guarded gotos can be used, for example, to model if -statements. The guard is then set to the negated condition of the -statement, and goto target is set to bypass the conditionally executed code -if this guard evaluates to true. -
ASSUMEAn assumption statement that restricts viable paths reaching the -instruction location to the ones that make the expression guard -evaluate to true.
ASSERTAn assertion whose guard is checked for validity when the instruction is -reached.
RETURNA return statement in a function.
END_FUNCTIONDenotes the end of a function.
ASSIGNA variable assignment.
SKIPNo operation.
OTHERAny operation not covered by enum -goto_program_instruction_typet.
- -

-A number of convenience functions in instructiont, such as -is_goto(), is_assume(), etc., simplify type queries. -The following code segment gives a partial interface declaration of -goto_program_template and instructiont. -

- -
template <class codeT, class guardT>
-class goto_program_templatet
-{
-public:
-  //list of instruction type
-  typedef std::list<class instructiont> instructionst;
-
-  //a reference to an instruction in the list
-  typedef typename 
-    std::list::iterator targett;
-
-  //Sequential list of instructions, 
-  //representing sequential program flow
-  instructionst instructions;
-
-  typedef typename 
-    std::map<const_targett, unsigned> target_numberst;
-
-  //A map containing the unique number of each target
-  target_numberst target_numbers;
-
-  //Get the successors of a given instruction 
-  void get_successors(targett target, targetst &successors); 
-
-  ...
-
- 
-  class instructiont
-  {
-  public:
-    codeT code;
-    
-    //identifier of enclosing function
-    irep_idt function;
-    
-    //location in the source file
-    locationt location;
-    
-    //type of instruction?
-    goto_program_instruction_typet type;
-
-    //Guard statement for gotos, assume, assert 
-    guardT guard;
-    
-    //targets for gotos
-    targetst targets;
-   
-    //set of all predecessors (sequential, and gotos)
-    std::set<targett> incoming_edges;
-    
-    // a globally unique number to identify a 
-    // program location. It is guaranteed to be 
-    // ordered in program order within one 
-    // goto_program
-    unsigned location_number;
-    
-    // a globally unique number to identify loops
-    unsigned loop_number;
-    
-    // true if this is a goto jumping back to an 
-    // earlier instruction in the sequential program 
-    // flow
-    bool is_backwards_goto() const;
-  };
-
-}
-
- - - - - - diff --git a/doc/html-manual/footer.inc b/doc/html-manual/footer.inc deleted file mode 100644 index 3e1257f5a2..0000000000 --- a/doc/html-manual/footer.inc +++ /dev/null @@ -1,5 +0,0 @@ - - - - - diff --git a/doc/html-manual/goto-cc-apache.shtml b/doc/html-manual/goto-cc-apache.shtml deleted file mode 100644 index 2a54f1b3ae..0000000000 --- a/doc/html-manual/goto-cc-apache.shtml +++ /dev/null @@ -1,69 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Example: Extracting Models from the Apache HTTPD

- -

-The Apache HTTPD is still the most -frequently used web server. Together with the relevant libraries, it -consists of around 0.4 million lines of C code. In the following, we show -how to extract models from Apache HTTPD 2.4.2. -

- -
    - -

  1. -First of all, we download the sources of Apache HTTPD and two supporting -libraries and uncompress them:

    - -

    -  lwp-download http://www.mirrorservice.org/sites/ftp.apache.org/apr/apr-1.4.6.tar.bz2
    -  lwp-download http://www.mirrorservice.org/sites/ftp.apache.org/apr/apr-util-1.4.1.tar.bz2
    -  lwp-download http://mirror.catn.com/pub/apache/httpd/httpd-2.4.2.tar.bz2
    -
    -  bunzip2 < apr-1.4.6.tar.bz2 | tar x
    -  bunzip2 < apr-util-1.4.1.tar.bz2 | tar x
    -  bunzip2 < httpd-2.4.2.tar.bz2 | tar x -

    2. - -

  2. Now compile -gcc-wrap.c and put the resulting binary -into a directory that is in your PATH variable:

    -

    -  lwp-download http://www.cprover.org/cprover-manual/gcc-wrap.c
    -  gcc gcc-wrap.c -o gcc-wrap
    -  cp gcc-wrap ~/bin/
    -

    -

    This assumes that the directory ~/bin -exists and is in your PATH variable.

    -
    3. - -

  3. We now build the sources with gcc:

    - -

    -  (cd apr-1.4.6; ./configure; make CC=gcc-wrap)
    -  (cd apr-util-1.4.1; ./configure --with-apr=../apr-1.4.6 ; make CC=gcc-wrap)
    -  (cd httpd-2.4.2; ./configure --with-apr=../apr-1.4.6 --with-apr-util=../apr-util-1.4.1 ; make CC=gcc-wrap) -

    - -

  4. You can now compile the preprocessed -source files with goto-cc as follows:

    -

    -  find ./ -name *.i > source-file-list
    -  for a in `cat source-file-list` ; do
    -    goto-cc -c $a -o $a.gb
    -  done

    -
    5. - -
- -

-The resulting .gb files can be passed to any -of the CPROVER tools. -

- - - diff --git a/doc/html-manual/goto-cc-linux.shtml b/doc/html-manual/goto-cc-linux.shtml deleted file mode 100644 index 52ecbfb229..0000000000 --- a/doc/html-manual/goto-cc-linux.shtml +++ /dev/null @@ -1,97 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Example: Extracting Models from the Linux Kernel

- -

- -The Linux kernel code consists of more than 11 million lines of low-level C -and is frequently used to evaluate static analysis techniques. In the -following, we show how to extract models from Linux 2.6.39. -

- -
    -

  1. -First of all, you will need to make sure you have around 100 GB -of free disc space available.

    2. - -

  2. Download the Kernel sources at - -http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.tar.bz2 -. -

    3. - -

  3. Now do

    -

    -  bunzip2 linux-2.6.39.tar.bz2
    -  tar xvf linux-2.6.39.tar
    -  cd linux-2.6.39 -

    4. - -

  4. Now ensure that you can actually -compile a kernel by doing

    -

    -  make defconfig
    -  make

    -

    -These steps need to succeed before you can try to extract -models from the kernel. -

    5. - -

  5. Now compile -gcc-wrap.c and put the resulting binary -into a directory that is in your PATH variable:

    -

    -  lwp-download http://www.cprover.org/cprover-manual/gcc-wrap.c
    -  gcc gcc-wrap.c -o gcc-wrap
    -  cp gcc-wrap ~/bin/
    -

    -

    This assumes that the directory ~/bin -exists and is in your PATH variable.

    -
    6. - -

  6. Now change the variable CC in the kernel -Makefile as follows:

    -

    -  CC = ~/bin/gcc-wrap -

    -
    7. - -

  7. Now do

    -

    -  make clean
    -  make

    -

    -This will re-compile the kernel, but this time retaining the -preprocessed source files. -

    8. - -

  8. You can now compile the preprocessed -source files with goto-cc as follows:

    -

    -  find ./ -name .tmp_*.i > source-file-list
    -  for a in `cat source-file-list` ; do
    -    goto-cc -c $a -o $a.gb
    -  done

    - -

    Note that it is important that the -word-size of the kernel configuration matches that of goto-cc. -Otherwise, compile-time assertions will fail, generating -the error message "bit field size is negative". For a kernel -configured for a 64-bit word-width, pass the option ---64 to goto-cc.

    - -
    9. - -
- -

-The resulting .gb files can be passed to any -of the CPROVER tools. -

- - - diff --git a/doc/html-manual/goto-cc-rockbox.shtml b/doc/html-manual/goto-cc-rockbox.shtml deleted file mode 100644 index 7bae0855bf..0000000000 --- a/doc/html-manual/goto-cc-rockbox.shtml +++ /dev/null @@ -1,83 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Example: Extracting Models from the Rockbox

- -

-The Rockbox is an open-source software -package for common MP3 players, with about 1 million lines of code in total. -

- -
    -

  1. -First of all, you will need to install one of the cross-compilers. Follow -the instructions here. -

    2. - -

  2. -You will then need to check out the Rockbox sources with GIT, and -configure and compile the code. Follow -these instructions. The build must succeed. -We will assume that one of the ARM-based targets -is used, and that the ARM cross-compiler is installed -at /usr/local/bin/arm-elf-eabi-gcc. -

    3. - -

  3. Now download -gcc-wrap.c:

    -

    -  lwp-download http://www.cprover.org/cprover-manual/gcc-wrap.c
    -

    -
    4. - -

  4. Open gcc-wrap.c in your favorite editor, -and adjust the path to gcc (in the first line) to -/usr/local/bin/arm-elf-eabi-gcc (it is important that the -full path is given). -

    5. - -

  5. Now compile gcc-wrap:

    -

    -  gcc gcc-wrap.c -o gcc-wrap-arm-elf-eabi-gcc
    -  cp gcc-wrap-arm-elf-eabi-gcc ~/bin/
    -

    -

    This assumes that the directory ~/bin -exists and is in your PATH variable.

    -
    6. - -

  6. Now re-compile the Rockbox code as follows:

    -

    -  make clean
    -  make CC=gcc-wrap-arm-elf-eabi-gcc

    -

    -This will re-compile the Rockbox, but this time retaining the -preprocessed source files. -

    7. - -

  7. You can now compile the preprocessed -source files with goto-cc as follows:

    -

    -  find ./ -name \*.i > source-file-list
    -  for a in `cat source-file-list` ; do
    -    goto-cc -std=gnu99 -m32 -c $a -o $a.gb
    -  done

    - -

    Note that it is important that the -word-size of the target platform matches that of goto-cc. -For a 32-bit target, pass the option --m32 to goto-cc.

    - -
    8. - -
- -

-The resulting .gb files can be passed to any -of the CPROVER tools. -

- - - diff --git a/doc/html-manual/goto-cc-variants.shtml b/doc/html-manual/goto-cc-variants.shtml deleted file mode 100644 index a7c5844325..0000000000 --- a/doc/html-manual/goto-cc-variants.shtml +++ /dev/null @@ -1,48 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Variants of goto-cc

- -

-The goto-cc utility comes in several variants, summarised in the following table. -

- -
- - - - - - - - - - - - - - - - - - -
ExecutableEnvironmentPreprocessor
goto-ccgcc (control-flow graph only)gcc -E
goto-gccgcc ("hybrid" executable)gcc -E
goto-armccARM RVDSarmcc -E
goto-clVisual Studiocl /E
goto-cwFreescale CodeWarriormwcceppc
-
- -

- -The primary difference between the variants is the preprocessor called. -Furthermore, the language recognized varies slightly. The variants can be -obtained by simply renaming the goto-cc executable. On Linux/MacOS, the -variants can be obtained by creating a symbolic link.

- -

-The "hybrid" -executables contain both the control-flow graph for verification purposes -and the usual, executable machine code. -

- - diff --git a/doc/html-manual/goto-cc-visual-studio.shtml b/doc/html-manual/goto-cc-visual-studio.shtml deleted file mode 100644 index a7ab178e9a..0000000000 --- a/doc/html-manual/goto-cc-visual-studio.shtml +++ /dev/null @@ -1,57 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Integration into Visual Studio 2008 to 2012

- -

-Visual Studio version 2008 onwards comes with a new XML-based -build system called MSBuild. -The MSBuild system is also activated when triggering a build from the Visual Studio GUI. -The project files created by the Visual Studio GUI are used as input by the MSBuild tool. -

- -

-The MSBuild system can be used to generate goto-binaries from your Visual Studio project -as follows: -

- -
    - -

  1. -Install the goto-cl.exe and goto-link.exe binaries -in some directory that is contained in the PATH environment -variable.

    2. - -

  2. Add a configuration for the goto-cc build for your project -in the configuration manager, named "goto-cc".

    3. - -

  3. Open the Visual Studio Command Prompt (in the Tools menu).

    4. - -

  4. Locate the directory that contains the project. Change into this -directory using "CD".

    5. - -

  5. Type

    -

    - -msbuild /p:CLToolExe=goto-cl.exe /p:LinkToolExe=goto-link.exe
    -   /p:Flavor=goto-cc /p:Platform=x86 -     -

    - -

    -The platform can be adjusted as required; the "Flavor" given should match -the configuration that was created earlier. -

    6. - -
- -

-Note that the recent versions of goto-cc also support file names with -non-ASCII (Unicode) characters on Windows platforms. -

- - - diff --git a/doc/html-manual/goto-cc.shtml b/doc/html-manual/goto-cc.shtml deleted file mode 100644 index cdc3c7d340..0000000000 --- a/doc/html-manual/goto-cc.shtml +++ /dev/null @@ -1,144 +0,0 @@ - - -

CPROVER Manual TOC

- -

Build Systems and Libraries

- -

Integration into Build Systems with goto-cc

- -

-Existing software projects usually do not come in a single source file that -may simply be passed to a model checker. They rather come in a multitude of -source files in different directories and refer to external libraries and -system-wide options. A build system then collects the configuration options -from the system and compiles the software according to build rules. -

- -

-The most prevalent build tool on Unix (-based) systems surely is the -make utility. This tool uses build rules given in a -Makefile that comes with the software sources. Running software -verification tools on projects like these is greatly simplified by a -compiler that first collects all the necessary models into a single -model file. goto-cc -is such a model file extractor, which can seamlessly replace gcc -and cl.exe in Makefiles. The normal build system for the -project may be used to build the software, but the outcome will be a -model file with suitable detail for verification, as opposed to a -flat executable program. Note that goto-cc comes in different variants -depending on the compilation environment. These variants -are described here. -

- -

Example: Building wu-ftpd

- -

This example assumes a Unix-like machine.

- -
    - -

  1. Download the sources of wu-ftpd from - - here. -

    2. - -

  2. Unpack the sources by running - tar xfz wu-ftpd-current.tar.gz -

    3. - -

  3. Change to the source directory, by entering, e.g., - cd wu-ftpd-2.6.2 -

    4. - -

  4. Configure the project for verification by running -

    -
    - ./configure YACC=byacc CC=goto-cc --host=none-none-none -
    -
    5. - -

  5. Build the project by running - make. - This creates multiple model files in the src directory. Among - them is a model for the main executable ftpd. -

    6. - -

  6. Run a model-checker, e.g., CBMC, - on the model file: -

    -
    - cbmc src/ftpd -
    -

    CBMC automatically recognizes that the file -is a goto binary. -

    -
    7. - -
- -

Important Notes

- -

-More elaborate build or configuration scripts often make use of -features of the compiler or the system library to detect configuration -options automatically, e.g., in a configure script. -Replacing gcc by goto-cc at this stage may confuse the script, -or detect wrong options. For example, missing library functions do not -cause goto-cc to throw an error (only to issue a warning). Because of -this, configuration scripts sometimes falsely assume the availability -of a system function or library. -

- -

-In the case of this or similar problems, it is more advisable to -configure the project using the normal routine, and replacing the -compiler setting manually in the generated Makefiles, e.g., by -replacing lines like CC=gcc by CC=goto-cc. -

- -

-A helpful command that accomplishes this task successfully for many -projects is the following: -

- - -for i in `find . -name Makefile`; do
-  sed -e 's/^\(\s*CC[ \t]*=\)\(.*$\)/\1goto-cc/g' -i $i
-done - - -

Here are additional examples on how to use goto-cc:

- - - -

A description -of how to integrate goto-cc into Microsoft's Visual Studio -is here.

- -

Linking Libraries

- -

-Some software projects come with their own libraries; also, the goal may be -to analyze a library by itself. For this purpose it is possible to use -goto-cc to link multiple model files into a library of model files. An -object file can then be linked against this model library. For this purpose, -goto-cc also features a linker mode. -

- -

-To enable this linker mode, create a link to the goto-cc binary by the -name of goto-ld (Linux and Mac) or copy the goto-cc binary to goto-link.exe -(Windows). The goto-ld tool can now be used as a seamless replacement -for the ld tool present on most Unix (-based) systems and -for the link tool on Windows. -

- -

-The default linker may need to be replaced by goto-ld or -goto-link.exe in the build -script, which can be achieved in much the same way as replacing the compiler. -

- - diff --git a/doc/html-manual/header.inc b/doc/html-manual/header.inc deleted file mode 100644 index 4624f036f2..0000000000 --- a/doc/html-manual/header.inc +++ /dev/null @@ -1,23 +0,0 @@ - - - - - -CPROVER Manual - - - - - - -
-
- - diff --git a/doc/html-manual/highlight/CHANGES.md b/doc/html-manual/highlight/CHANGES.md deleted file mode 100644 index 38cd2733c3..0000000000 --- a/doc/html-manual/highlight/CHANGES.md +++ /dev/null @@ -1,1610 +0,0 @@ -## Version 9.11.0 - -New languages: - -- *Shell* by [Tsuyusato Kitsune][] -- *jboss-cli* by [Raphaël Parrëe][] - -Improvements: - -- [Joël Porquet] has [greatly improved the definition of *makefile*][5b3e0e6]. -- *C++* class titles are now highlighted as in other languages with classes. -- [Jordi Petit][] added rarely used `or`, `and` and `not` keywords to *C++*. -- [Pieter Vantorre][] fixed highlighting of negative floating point values. - - -[Tsuyusato Kitsune]: https://github.com/MakeNowJust -[Jordi Petit]: https://github.com/jordi-petit -[Raphaël Parrëe]: https://github.com/rparree -[Pieter Vantorre]: https://github.com/NuclearCookie -[5b3e0e6]: https://github.com/isagalaev/highlight.js/commit/5b3e0e68bfaae282faff6697d6a490567fa9d44b - - -## Version 9.10.0 - -Apologies for missing the previous release cycle. Some thing just can't be -automated… Anyway, we're back! - -New languages: - -- *Hy* by [Sergey Sobko][] -- *Leaf* by [Hale Chan][] -- *N1QL* by [Andres Täht][] and [Rene Saarsoo][] - -Improvements: - -- *Rust* got updated with new keywords by [Kasper Andersen][] and then - significantly modernized even more by [Eduard-Mihai Burtescu][] (yes, @eddyb, - Rust core team member!) -- *Python* updated with f-literals by [Philipp A][]. -- *YAML* updated with unquoted strings support. -- *Gauss* updated with new keywords by [Matt Evans][]. -- *Lua* updated with new keywords by [Joe Blow][]. -- *Kotlin* updated with new keywords by [Philipp Hauer][]. -- *TypeScript* got highlighting of function params and updated keywords by - [Ike Ku][]. -- *Scheme* now correctly handles \`-quoted lists thanks to [Guannan Wei]. -- [Sam Wu][] fixed handling of `<<` in *C++* defines. - -[Philipp A]: https://github.com/flying-sheep -[Philipp Hauer]: https://github.com/phauer -[Sergey Sobko]: https://github.com/profitware -[Hale Chan]: https://github.com/halechan -[Matt Evans]: https://github.com/matthewevans -[Joe Blow]: https://github.com/mossarelli -[Kasper Andersen]: https://github.com/kasma1990 -[Eduard-Mihai Burtescu]: https://github.com/eddyb -[Andres Täht]: https://github.com/andrestaht -[Rene Saarsoo]: https://github.com/nene -[Philipp Hauer]: https://github.com/phauer -[Ike Ku]: https://github.com/dempfi -[Guannan Wei]: https://github.com/Kraks -[Sam Wu]: https://github.com/samsam2310 - - -## Version 9.9.0 - -New languages - -- *LLVM* by [Michael Rodler][] - -Improvements: - -- *TypeScript* updated with annotations and param lists inside constructors, by - [Raphael Parree][]. -- *CoffeeScript* updated with new keywords and fixed to recognize JavaScript - in \`\`\`, thanks to thanks to [Geoffrey Booth][]. -- Compiler directives in *Delphi* are now correctly highlighted as "meta". - -[Raphael Parree]: https://github.com/rparree -[Michael Rodler]: https://github.com/f0rki -[Geoffrey Booth]: https://github.com/GeoffreyBooth - - -## Version 9.8.0 "New York" - -This version is the second one that deserved a name. Because I'm in New York, -and the release isn't missing the deadline only because it's still Tuesday on -West Coast. - -New languages: - -- *Clean* by [Camil Staps][] -- *Flix* by [Magnus Madsen][] - -Improvements: - -- [Kenton Hamaluik][] did a comprehensive update for *Haxe*. -- New commands for *PowerShell* from [Nicolas Le Gall][]. -- [Jan T. Sott][] updated *NSIS*. -- *Java* and *Swift* support unicode characters in identifiers thanks to - [Alexander Lichter][]. - -[Camil Staps]: https://github.com/camilstaps -[Magnus Madsen]: https://github.com/magnus-madsen -[Kenton Hamaluik]: https://github.com/FuzzyWuzzie -[Nicolas Le Gall]: https://github.com/darkitty -[Jan T. Sott]: https://github.com/idleberg -[Alexander Lichter]: https://github.com/manniL - - -## Version 9.7.0 - -A comprehensive bugfix release. This is one of the best things about -highlight.js: even boring things keep getting better (even if slow). - -- VHDL updated with PSL keywords and uses more consistent styling. -- Nested C-style comments no longer break highlighting in many languages. -- JavaScript updated with `=>` functions, highlighted object attributes and - parsing within template string substitution blocks (`${...}`). -- Fixed another corner case with self-closing `` in JSX. -- Added `HEALTHCHECK` directive in Docker. -- Delphi updated with new Free Pascal keywords. -- Fixed digit separator parsing in C++. -- C# updated with new keywords and fixed to allow multiple identifiers within - generics `<...>`. -- Fixed another slow regex in Less. - - -## Version 9.6.0 - -New languages: - -- *ABNF* and *EBNF* by [Alex McKibben][] -- *Awk* by [Matthew Daly][] -- *SubUnit* by [Sergey Bronnikov][] - -New styles: - -- *Atom One* in both Dark and Light variants by [Daniel Gamage][] - -Plus, a few smaller updates for *Lasso*, *Elixir*, *C++* and *SQL*. - -[Alex McKibben]: https://github.com/mckibbenta -[Daniel Gamage]: https://github.com/danielgamage -[Matthew Daly]: https://github.com/matthewbdaly -[Sergey Bronnikov]: https://github.com/ligurio - - -## Version 9.5.0 - -New languages: - -- *Excel* by [Victor Zhou][] -- *Linden Scripting Language* by [Builder's Brewery][] -- *TAP* (Test Anything Protocol) by [Sergey Bronnikov][] -- *Pony* by [Joe Eli McIlvain][] -- *Coq* by [Stephan Boyer][] -- *dsconfig* and *LDIF* by [Jacob Childress][] - -New styles: - -- *Ocean Dark* by [Gavin Siu][] - -Notable changes: - -- [Minh Nguyễn][] added more built-ins to Objective C. -- [Jeremy Hull][] fixed corner cases in C++ preprocessor directives and Diff - comments. -- [Victor Zhou][] added support for digit separators in C++ numbers. - -[Gavin Siu]: https://github.com/gavsiu -[Builder's Brewery]: https://github.com/buildersbrewery -[Victor Zhou]: https://github.com/OiCMudkips -[Sergey Bronnikov]: https://github.com/ligurio -[Joe Eli McIlvain]: https://github.com/jemc -[Stephan Boyer]: https://github.com/boyers -[Jacob Childress]: https://github.com/braveulysses -[Minh Nguyễn]: https://github.com/1ec5 -[Jeremy Hull]: https://github.com/sourrust - - -## Version 9.4.0 - -New languages: - -- *PureBASIC* by [Tristano Ajmone][] -- *BNF* by [Oleg Efimov][] -- *Ada* by [Lars Schulna][] - -New styles: - -- *PureBASIC* by [Tristano Ajmone][] - -Improvements to existing languages and styles: - -- We now highlight function declarations in Go. -- [Taisuke Fujimoto][] contributed very convoluted rules for raw and - interpolated strings in C#. -- [Boone Severson][] updated Verilog to comply with IEEE 1800-2012 - SystemVerilog. -- [Victor Zhou][] improved rules for comments and strings in PowerShell files. -- [Janis Voigtländer][] updated the definition of Elm to version 0.17 of the - languages. Elm is now featured on the front page of . -- Special variable `$this` is highlighted as a keyword in PHP. -- `usize` and `isize` are now highlighted in Rust. -- Fixed labels and directives in x86 assembler. - -[Tristano Ajmone]: https://github.com/tajmone -[Taisuke Fujimoto]: https://github.com/temp-impl -[Oleg Efimov]: https://github.com/Sannis -[Boone Severson]: https://github.com/BooneJS -[Victor Zhou]: https://github.com/OiCMudkips -[Lars Schulna]: https://github.com/captain-hanuta -[Janis Voigtländer]: https://github.com/jvoigtlaender - - -## Version 9.3.0 - -New languages: - -- *Tagger Script* by [Philipp Wolfer][] -- *MoonScript* by [Billy Quith][] - -New styles: - -- *xt256* by [Herbert Shin][] - -Improvements to existing languages and styles: - -- More robust handling of unquoted HTML tag attributes -- Relevance tuning for QML which was unnecessary eager at seizing other - languages' code -- Improve GAMS language parsing -- Fixed a bunch of bugs around selectors in Less -- Kotlin's got a new definition for annotations, updated keywords and other - minor improvements -- Added `move` to Rust keywords -- Markdown now recognizes \`\`\`-fenced code blocks -- Improved detection of function declarations in C++ and C# - -[Philipp Wolfer]: https://github.com/phw -[Billy Quith]: https://github.com/billyquith -[Herbert Shin]: https://github.com/initbar - - -## Version 9.2.0 - -New languages: - -- *QML* by [John Foster][] -- *HTMLBars* by [Michael Johnston][] -- *CSP* by [Taras][] -- *Maxima* by [Robert Dodier][] - -New styles: - -- *Gruvbox* by [Qeole][] -- *Dracula* by [Denis Ciccale][] - -Improvements to existing languages and styles: - -- We now correctly handle JSX with arbitrary node tree depth. -- Argument list for `(lambda)` in Scheme is no longer highlighted as a function - call. -- Stylus syntax doesn't break on valid CSS. -- More correct handling of comments and strings and other improvements for - VimScript. -- More subtle work on the default style. -- We now use anonymous modules for AMD. -- `macro_rules!` is now recognized as a built-in in Rust. - -[John Foster]: https://github.com/jf990 -[Qeole]: https://github.com/Qeole -[Denis Ciccale]: https://github.com/dciccale -[Michael Johnston]: https://github.com/lastobelus -[Taras]: https://github.com/oxdef -[Robert Dodier]: https://github.com/robert-dodier - - -## Version 9.1.0 - -New languages: - -- *Stan* by [Brendan Rocks][] -- *BASIC* by [Raphaël Assénat][] -- *GAUSS* by [Matt Evans][] -- *DTS* by [Martin Braun][] -- *Arduino* by [Stefania Mellai][] - -New Styles: - -- *Arduino Light* by [Stefania Mellai][] - -Improvements to existing languages and styles: - -- Handle return type annotations in Python -- Allow shebang headers in Javascript -- Support strings in Rust meta -- Recognize `struct` as a class-level definition in Rust -- Recognize b-prefixed chars and strings in Rust -- Better numbers handling in Verilog - -[Brendan Rocks]: http://brendanrocks.com -[Raphaël Assénat]: https://github.com/raphnet -[Matt Evans]: https://github.com/matthewevans -[Martin Braun]: https://github.com/mbr0wn -[Stefania Mellai]: https://github.com/smellai - - -## Version 9.0.0 - -The new major version brings a reworked styling system. Highlight.js now defines -a limited set of highlightable classes giving a consistent result across all the -styles and languages. You can read a more detailed explanation and background in -the [tracking issue][#348] that started this long process back in May. - -This change is backwards incompatible for those who uses highlight.js with a -custom stylesheet. The [new style guide][sg] explains how to write styles -in this new world. - -Bundled themes have also suffered a significant amount of improvements and may -look different in places, but all the things now consistent and make more sense. -Among others, the Default style has got a refresh and will probably be tweaked -some more in next releases. Please do give your feedback in our -[issue tracker][issues]. - -New languages in this release: - -- *Caché Object Script* by [Nikita Savchenko][] -- *YAML* by [Stefan Wienert][] -- *MIPS Assembler* by [Nebuleon Fumika][] -- *HSP* by [prince][] - -Improvements to existing languages and styles: - -- ECMAScript 6 modules import now do not require closing semicolon. -- ECMAScript 6 classes constructors now highlighted. -- Template string support for Typescript, as for ECMAScript 6. -- Scala case classes params highlight fixed. -- Built-in names introduced in Julia v0.4 added by [Kenta Sato][]. -- Refreshed Default style. - -Other notable changes: - -- [Web workers support][webworkers] added bu [Jan Kühle][]. -- We now have tests for compressed browser builds as well. -- The building tool chain has been switched to node.js 4.x. and is now - shamelessly uses ES6 features all over the place, courtesy of [Jeremy Hull][]. -- License added to non-compressed browser build. - -[Jan Kühle]: https://github.com/frigus02 -[Stefan Wienert]: https://github.com/zealot128 -[Kenta Sato]: https://github.com/bicycle1885 -[Nikita Savchenko]: https://github.com/ZitRos -[webworkers]: https://github.com/isagalaev/highlight.js#web-workers -[Jeremy Hull]: https://github.com/sourrust -[#348]: https://github.com/isagalaev/highlight.js/issues/348 -[sg]: http://highlightjs.readthedocs.org/en/latest/style-guide.html -[issues]: https://github.com/isagalaev/highlight.js/issues -[Nebuleon Fumika]: https://github.com/Nebuleon -[prince]: https://github.com/prince-0203 - - -## Version 8.9.1 - -Some last-minute changes reverted due to strange bug with minified browser build: - -- Scala case classes params highlight fixed -- ECMAScript 6 modules import now do not require closing semicolon -- ECMAScript 6 classes constructors now highlighted -- Template string support for Typescript, as for ECMAScript 6 -- License added to not minified browser build - - -## Version 8.9.0 - -New languages: - -- *crmsh* by [Kristoffer Gronlund][] -- *SQF* by [Soren Enevoldsen][] - -[Kristoffer Gronlund]: https://github.com/krig -[Soren Enevoldsen]: https://github.com/senevoldsen90 - -Notable fixes and improvements to existing languages: - -- Added `abstract` and `namespace` keywords to TypeScript by [Daniel Rosenwasser][] -- Added `label` support to Dockerfile by [Ladislav Prskavec][] -- Crystal highlighting improved by [Tsuyusato Kitsune][] -- Missing Swift keywords added by [Nate Cook][] -- Improve detection of C block comments -- ~~Scala case classes params highlight fixed~~ -- ~~ECMAScript 6 modules import now do not require closing semicolon~~ -- ~~ECMAScript 6 classes constructors now highlighted~~ -- ~~Template string support for Typescript, as for ECMAScript 6~~ - -Other notable changes: - -- ~~License added to not minified browser build~~ - -[Kristoffer Gronlund]: https://github.com/krig -[Søren Enevoldsen]: https://github.com/senevoldsen90 -[Daniel Rosenwasser]: https://github.com/DanielRosenwasser -[Ladislav Prskavec]: https://github.com/abtris -[Tsuyusato Kitsune]: https://github.com/MakeNowJust -[Nate Cook]: https://github.com/natecook1000 - - -## Version 8.8.0 - -New languages: - -- *Golo* by [Philippe Charrière][] -- *GAMS* by [Stefan Bechert][] -- *IRPF90* by [Anthony Scemama][] -- *Access logs* by [Oleg Efimov][] -- *Crystal* by [Tsuyusato Kitsune][] - -Notable fixes and improvements to existing languages: - -- JavaScript highlighting no longer fails with ES6 default parameters -- Added keywords `async` and `await` to Python -- PHP heredoc support improved -- Allow preprocessor directives within C++ functions - -Other notable changes: - -- Change versions to X.Y.Z SemVer-compatible format -- Added ability to build all targets at once - -[Philippe Charrière]: https://github.com/k33g -[Stefan Bechert]: https://github.com/b-pos465 -[Anthony Scemama]: https://github.com/scemama -[Oleg Efimov]: https://github.com/Sannis -[Tsuyusato Kitsune]: https://github.com/MakeNowJust - - -## Version 8.7 - -New languages: - -- *Zephir* by [Oleg Efimov][] -- *Elm* by [Janis Voigtländer][] -- *XQuery* by [Dirk Kirsten][] -- *Mojolicious* by [Dotan Dimet][] -- *AutoIt* by Manh Tuan from [J2TeaM][] -- *Toml* (ini extension) by [Guillaume Gomez][] - -New styles: - -- *Hopscotch* by [Jan T. Sott][] -- *Grayscale* by [MY Sun][] - -Notable fixes and improvements to existing languages: - -- Fix encoding of images when copied over in certain builds -- Fix incorrect highlighting of the word "bug" in comments -- Treat decorators different from matrix multiplication in Python -- Fix traits inheritance highlighting in Rust -- Fix incorrect document -- Oracle keywords added to SQL language definition by [Vadimtro][] -- Postgres keywords added to SQL language definition by [Benjamin Auder][] -- Fix registers in x86asm being highlighted as a hex number -- Fix highlighting for numbers with a leading decimal point -- Correctly highlight numbers and strings inside of C/C++ macros -- C/C++ functions now support pointer, reference, and move returns - -[Oleg Efimov]: https://github.com/Sannis -[Guillaume Gomez]: https://github.com/GuillaumeGomez -[Janis Voigtländer]: https://github.com/jvoigtlaender -[Jan T. Sott]: https://github.com/idleberg -[Dirk Kirsten]: https://github.com/dirkk -[MY Sun]: https://github.com/simonmysun -[Vadimtro]: https://github.com/Vadimtro -[Benjamin Auder]: https://github.com/ghost -[Dotan Dimet]: https://github.com/dotandimet -[J2TeaM]: https://github.com/J2TeaM - - -## Version 8.6 - -New languages: - -- *C/AL* by [Kenneth Fuglsang][] -- *DNS zone file* by [Tim Schumacher][] -- *Ceylon* by [Lucas Werkmeister][] -- *OpenSCAD* by [Dan Panzarella][] -- *Inform7* by [Bruno Dias][] -- *armasm* by [Dan Panzarella][] -- *TP* by [Jay Strybis][] - -New styles: - -- *Atelier Cave*, *Atelier Estuary*, - *Atelier Plateau* and *Atelier Savanna* by [Bram de Haan][] -- *Github Gist* by [Louis Barranqueiro][] - -Notable fixes and improvements to existing languages: - -- Multi-line raw strings from C++11 are now supported -- Fix class names with dashes in HAML -- The `async` keyword from ES6/7 is now supported -- TypeScript functions handle type and parameter complexity better -- We unified phpdoc/javadoc/yardoc etc modes across all languages -- CSS .class selectors relevance was dropped to prevent wrong language detection -- Images is now included to CDN build -- Release process is now automated - -[Bram de Haan]: https://github.com/atelierbram -[Kenneth Fuglsang]: https://github.com/kfuglsang -[Louis Barranqueiro]: https://github.com/LouisBarranqueiro -[Tim Schumacher]: https://github.com/enko -[Lucas Werkmeister]: https://github.com/lucaswerkmeister -[Dan Panzarella]: https://github.com/pzl -[Bruno Dias]: https://github.com/sequitur -[Jay Strybis]: https://github.com/unreal - - -## Version 8.5 - -New languages: - -- *pf.conf* by [Peter Piwowarski][] -- *Julia* by [Kenta Sato][] -- *Prolog* by [Raivo Laanemets][] -- *Docker* by [Alexis Hénaut][] -- *Fortran* by [Anthony Scemama][] and [Thomas Applencourt][] -- *Kotlin* by [Sergey Mashkov][] - -New styles: - -- *Agate* by [Taufik Nurrohman][] -- *Darcula* by [JetBrains][] -- *Atelier Sulphurpool* by [Bram de Haan][] -- *Android Studio* by [Pedro Oliveira][] - -Notable fixes and improvements to existing languages: - -- ES6 features in JavaScript are better supported now by [Gu Yiling][]. -- Swift now recognizes body-less method definitions. -- Single expression functions `def foo, do: ... ` now work in Elixir. -- More uniform detection of built-in classes in Objective C. -- Fixes for number literals and processor directives in Rust. -- HTML ` - ``` - -- `tabReplace` and `useBR` that were used in different places are also unified - into the global options object and are to be set using `configure(options)`. - This function is documented in our [API docs][]. Also note that these - parameters are gone from `highlightBlock` and `fixMarkup` which are now also - rely on `configure`. - -- We removed public-facing (though undocumented) object `hljs.LANGUAGES` which - was used to register languages with the library in favor of two new methods: - `registerLanguage` and `getLanguage`. Both are documented in our [API docs][]. - -- Result returned from `highlight` and `highlightAuto` no longer contains two - separate attributes contributing to relevance score, `relevance` and - `keyword_count`. They are now unified in `relevance`. - -Another technically compatible change that nonetheless might need attention: - -- The structure of the NPM package was refactored, so if you had installed it - locally, you'll have to update your paths. The usual `require('highlight.js')` - works as before. This is contributed by [Dmitry Smolin][]. - -New features: - -- Languages now can be recognized by multiple names like "js" for JavaScript or - "html" for, well, HTML (which earlier insisted on calling it "xml"). These - aliases can be specified in the class attribute of the code container in your - HTML as well as in various API calls. For now there are only a few very common - aliases but we'll expand it in the future. All of them are listed in the - [class reference][cr]. - -- Language detection can now be restricted to a subset of languages relevant in - a given context — a web page or even a single highlighting call. This is - especially useful for node.js build that includes all the known languages. - Another example is a StackOverflow-style site where users specify languages - as tags rather than in the markdown-formatted code snippets. This is - documented in the [API reference][] (see methods `highlightAuto` and - `configure`). - -- Language definition syntax streamlined with [variants][] and - [beginKeywords][]. - -New languages and styles: - -- *Oxygene* by [Carlo Kok][] -- *Mathematica* by [Daniel Kvasnička][] -- *Autohotkey* by [Seongwon Lee][] -- *Atelier* family of styles in 10 variants by [Bram de Haan][] -- *Paraíso* styles by [Jan T. Sott][] - -Miscellaneous improvements: - -- Highlighting `=>` prompts in Clojure. -- [Jeremy Hull][] fixed a lot of styles for consistency. -- Finally, highlighting PHP and HTML [mixed in peculiar ways][php-html]. -- Objective C and C# now properly highlight titles in method definition. -- Big overhaul of relevance counting for a number of languages. Please do report - bugs about mis-detection of non-trivial code snippets! - -[API reference]: http://highlightjs.readthedocs.org/en/latest/api.html - -[cr]: http://highlightjs.readthedocs.org/en/latest/css-classes-reference.html -[api docs]: http://highlightjs.readthedocs.org/en/latest/api.html -[variants]: https://groups.google.com/d/topic/highlightjs/VoGC9-1p5vk/discussion -[beginKeywords]: https://github.com/isagalaev/highlight.js/commit/6c7fdea002eb3949577a85b3f7930137c7c3038d -[php-html]: https://twitter.com/highlightjs/status/408890903017689088 - -[Carlo Kok]: https://github.com/carlokok -[Bram de Haan]: https://github.com/atelierbram -[Daniel Kvasnička]: https://github.com/dkvasnicka -[Dmitry Smolin]: https://github.com/dimsmol -[Jeremy Hull]: https://github.com/sourrust -[Seongwon Lee]: https://github.com/dlimpid -[Jan T. Sott]: https://github.com/idleberg - - -## Version 7.5 - -A catch-up release dealing with some of the accumulated contributions. This one -is probably will be the last before the 8.0 which will be slightly backwards -incompatible regarding some advanced use-cases. - -One outstanding change in this version is the addition of 6 languages to the -[hosted script][d]: Markdown, ObjectiveC, CoffeeScript, Apache, Nginx and -Makefile. It now weighs about 6K more but we're going to keep it under 30K. - -New languages: - -- OCaml by [Mehdi Dogguy][mehdid] and [Nicolas Braud-Santoni][nbraud] -- [LiveCode Server][lcs] by [Ralf Bitter][revig] -- Scilab by [Sylvestre Ledru][sylvestre] -- basic support for Makefile by [Ivan Sagalaev][isagalaev] - -Improvements: - -- Ruby's got support for characters like `?A`, `?1`, `?\012` etc. and `%r{..}` - regexps. -- Clojure now allows a function call in the beginning of s-expressions - `(($filter "myCount") (arr 1 2 3 4 5))`. -- Haskell's got new keywords and now recognizes more things like pragmas, - preprocessors, modules, containers, FFIs etc. Thanks to [Zena Treep][treep] - for the implementation and to [Jeremy Hull][sourrust] for guiding it. -- Miscellaneous fixes in PHP, Brainfuck, SCSS, Asciidoc, CMake, Python and F#. - -[mehdid]: https://github.com/mehdid -[nbraud]: https://github.com/nbraud -[revig]: https://github.com/revig -[lcs]: http://livecode.com/developers/guides/server/ -[sylvestre]: https://github.com/sylvestre -[isagalaev]: https://github.com/isagalaev -[treep]: https://github.com/treep -[sourrust]: https://github.com/sourrust -[d]: http://highlightjs.org/download/ - - -## New core developers - -The latest long period of almost complete inactivity in the project coincided -with growing interest to it led to a decision that now seems completely obvious: -we need more core developers. - -So without further ado let me welcome to the core team two long-time -contributors: [Jeremy Hull][] and [Oleg -Efimov][]. - -Hope now we'll be able to work through stuff faster! - -P.S. The historical commit is [here][1] for the record. - -[Jeremy Hull]: https://github.com/sourrust -[Oleg Efimov]: https://github.com/sannis -[1]: https://github.com/isagalaev/highlight.js/commit/f3056941bda56d2b72276b97bc0dd5f230f2473f - - -## Version 7.4 - -This long overdue version is a snapshot of the current source tree with all the -changes that happened during the past year. Sorry for taking so long! - -Along with the changes in code highlight.js has finally got its new home at -, moving from its cradle on Software Maniacs which it -outgrew a long time ago. Be sure to report any bugs about the site to -. - -On to what's new… - -New languages: - -- Handlebars templates by [Robin Ward][] -- Oracle Rules Language by [Jason Jacobson][] -- F# by [Joans Follesø][] -- AsciiDoc and Haml by [Dan Allen][] -- Lasso by [Eric Knibbe][] -- SCSS by [Kurt Emch][] -- VB.NET by [Poren Chiang][] -- Mizar by [Kelley van Evert][] - -[Robin Ward]: https://github.com/eviltrout -[Jason Jacobson]: https://github.com/jayce7 -[Joans Follesø]: https://github.com/follesoe -[Dan Allen]: https://github.com/mojavelinux -[Eric Knibbe]: https://github.com/EricFromCanada -[Kurt Emch]: https://github.com/kemch -[Poren Chiang]: https://github.com/rschiang -[Kelley van Evert]: https://github.com/kelleyvanevert - -New style themes: - -- Monokai Sublime by [noformnocontent][] -- Railscasts by [Damien White][] -- Obsidian by [Alexander Marenin][] -- Docco by [Simon Madine][] -- Mono Blue by [Ivan Sagalaev][] (uses a single color hue for everything) -- Foundation by [Dan Allen][] - -[noformnocontent]: http://nn.mit-license.org/ -[Damien White]: https://github.com/visoft -[Alexander Marenin]: https://github.com/ioncreature -[Simon Madine]: https://github.com/thingsinjars -[Ivan Sagalaev]: https://github.com/isagalaev - -Other notable changes: - -- Corrected many corner cases in CSS. -- Dropped Python 2 version of the build tool. -- Implemented building for the AMD format. -- Updated Rust keywords (thanks to [Dmitry Medvinsky][]). -- Literal regexes can now be used in language definitions. -- CoffeeScript highlighting is now significantly more robust and rich due to - input from [Cédric Néhémie][]. - -[Dmitry Medvinsky]: https://github.com/dmedvinsky -[Cédric Néhémie]: https://github.com/abe33 - - -## Version 7.3 - -- Since this version highlight.js no longer works in IE version 8 and older. - It's made it possible to reduce the library size and dramatically improve code - readability and made it easier to maintain. Time to go forward! - -- New languages: AppleScript (by [Nathan Grigg][ng] and [Dr. Drang][dd]) and - Brainfuck (by [Evgeny Stepanischev][bolk]). - -- Improvements to existing languages: - - - interpreter prompt in Python (`>>>` and `...`) - - @-properties and classes in CoffeeScript - - E4X in JavaScript (by [Oleg Efimov][oe]) - - new keywords in Perl (by [Kirk Kimmel][kk]) - - big Ruby syntax update (by [Vasily Polovnyov][vast]) - - small fixes in Bash - -- Also Oleg Efimov did a great job of moving all the docs for language and style - developers and contributors from the old wiki under the source code in the - "docs" directory. Now these docs are nicely presented at - . - -[ng]: https://github.com/nathan11g -[dd]: https://github.com/drdrang -[bolk]: https://github.com/bolknote -[oe]: https://github.com/Sannis -[kk]: https://github.com/kimmel -[vast]: https://github.com/vast - - -## Version 7.2 - -A regular bug-fix release without any significant new features. Enjoy! - - -## Version 7.1 - -A Summer crop: - -- [Marc Fornos][mf] made the definition for Clojure along with the matching - style Rainbow (which, of course, works for other languages too). -- CoffeeScript support continues to improve getting support for regular - expressions. -- Yoshihide Jimbo ported to highlight.js [five Tomorrow styles][tm] from the - [project by Chris Kempson][tm0]. -- Thanks to [Casey Duncun][cd] the library can now be built in the popular - [AMD format][amd]. -- And last but not least, we've got a fair number of correctness and consistency - fixes, including a pretty significant refactoring of Ruby. - -[mf]: https://github.com/mfornos -[tm]: http://jmblog.github.com/color-themes-for-highlightjs/ -[tm0]: https://github.com/ChrisKempson/Tomorrow-Theme -[cd]: https://github.com/caseman -[amd]: http://requirejs.org/docs/whyamd.html - - -## Version 7.0 - -The reason for the new major version update is a global change of keyword syntax -which resulted in the library getting smaller once again. For example, the -hosted build is 2K less than at the previous version while supporting two new -languages. - -Notable changes: - -- The library now works not only in a browser but also with [node.js][]. It is - installable with `npm install highlight.js`. [API][] docs are available on our - wiki. - -- The new unique feature (apparently) among syntax highlighters is highlighting - *HTTP* headers and an arbitrary language in the request body. The most useful - languages here are *XML* and *JSON* both of which highlight.js does support. - Here's [the detailed post][p] about the feature. - -- Two new style themes: a dark "south" *[Pojoaque][]* by Jason Tate and an - emulation of*XCode* IDE by [Angel Olloqui][ao]. - -- Three new languages: *D* by [Aleksandar Ružičić][ar], *R* by [Joe Cheng][jc] - and *GLSL* by [Sergey Tikhomirov][st]. - -- *Nginx* syntax has become a million times smaller and more universal thanks to - remaking it in a more generic manner that doesn't require listing all the - directives in the known universe. - -- Function titles are now highlighted in *PHP*. - -- *Haskell* and *VHDL* were significantly reworked to be more rich and correct - by their respective maintainers [Jeremy Hull][sr] and [Igor Kalnitsky][ik]. - -And last but not least, many bugs have been fixed around correctness and -language detection. - -Overall highlight.js currently supports 51 languages and 20 style themes. - -[node.js]: http://nodejs.org/ -[api]: http://softwaremaniacs.org/wiki/doku.php/highlight.js:api -[p]: http://softwaremaniacs.org/blog/2012/05/10/http-and-json-in-highlight-js/en/ -[pojoaque]: http://web-cms-designs.com/ftopict-10-pojoaque-style-for-highlight-js-code-highlighter.html -[ao]: https://github.com/angelolloqui -[ar]: https://github.com/raleksandar -[jc]: https://github.com/jcheng5 -[st]: https://github.com/tikhomirov -[sr]: https://github.com/sourrust -[ik]: https://github.com/ikalnitsky - - -## Version 6.2 - -A lot of things happened in highlight.js since the last version! We've got nine -new contributors, the discussion group came alive, and the main branch on GitHub -now counts more than 350 followers. Here are most significant results coming -from all this activity: - -- 5 (five!) new languages: Rust, ActionScript, CoffeeScript, MatLab and - experimental support for markdown. Thanks go to [Andrey Vlasovskikh][av], - [Alexander Myadzel][am], [Dmytrii Nagirniak][dn], [Oleg Efimov][oe], [Denis - Bardadym][db] and [John Crepezzi][jc]. - -- 2 new style themes: Monokai by [Luigi Maselli][lm] and stylistic imitation of - another well-known highlighter Google Code Prettify by [Aahan Krish][ak]. - -- A vast number of [correctness fixes and code refactorings][log], mostly made - by [Oleg Efimov][oe] and [Evgeny Stepanischev][es]. - -[av]: https://github.com/vlasovskikh -[am]: https://github.com/myadzel -[dn]: https://github.com/dnagir -[oe]: https://github.com/Sannis -[db]: https://github.com/btd -[jc]: https://github.com/seejohnrun -[lm]: http://grigio.org/ -[ak]: https://github.com/geekpanth3r -[es]: https://github.com/bolknote -[log]: https://github.com/isagalaev/highlight.js/commits/ - - -## Version 6.1 — Solarized - -[Jeremy Hull][jh] has implemented my dream feature — a port of [Solarized][] -style theme famous for being based on the intricate color theory to achieve -correct contrast and color perception. It is now available for highlight.js in -both variants — light and dark. - -This version also adds a new original style Arta. Its author pumbur maintains a -[heavily modified fork of highlight.js][pb] on GitHub. - -[jh]: https://github.com/sourrust -[solarized]: http://ethanschoonover.com/solarized -[pb]: https://github.com/pumbur/highlight.js - - -## Version 6.0 - -New major version of the highlighter has been built on a significantly -refactored syntax. Due to this it's even smaller than the previous one while -supporting more languages! - -New languages are: - -- Haskell by [Jeremy Hull][sourrust] -- Erlang in two varieties — module and REPL — made collectively by [Nikolay - Zakharov][desh], [Dmitry Kovega][arhibot] and [Sergey Ignatov][ignatov] -- Objective C by [Valerii Hiora][vhbit] -- Vala by [Antono Vasiljev][antono] -- Go by [Stephan Kountso][steplg] - -[sourrust]: https://github.com/sourrust -[desh]: http://desh.su/ -[arhibot]: https://github.com/arhibot -[ignatov]: https://github.com/ignatov -[vhbit]: https://github.com/vhbit -[antono]: https://github.com/antono -[steplg]: https://github.com/steplg - -Also this version is marginally faster and fixes a number of small long-standing -bugs. - -Developer overview of the new language syntax is available in a [blog post about -recent beta release][beta]. - -[beta]: http://softwaremaniacs.org/blog/2011/04/25/highlight-js-60-beta/en/ - -P.S. New version is not yet available on a Yandex CDN, so for now you have to -download [your own copy][d]. - -[d]: /soft/highlight/en/download/ - - -## Version 5.14 - -Fixed bugs in HTML/XML detection and relevance introduced in previous -refactoring. - -Also test.html now shows the second best result of language detection by -relevance. - - -## Version 5.13 - -Past weekend began with a couple of simple additions for existing languages but -ended up in a big code refactoring bringing along nice improvements for language -developers. - -### For users - -- Description of C++ has got new keywords from the upcoming [C++ 0x][] standard. -- Description of HTML has got new tags from [HTML 5][]. -- CSS-styles have been unified to use consistent padding and also have lost - pop-outs with names of detected languages. -- [Igor Kalnitsky][ik] has sent two new language descriptions: CMake & VHDL. - -This makes total number of languages supported by highlight.js to reach 35. - -Bug fixes: - -- Custom classes on `
` tags are not being overridden anymore
-- More correct highlighting of code blocks inside non-`
` containers:
-  highlighter now doesn't insist on replacing them with its own container and
-  just replaces the contents.
-- Small fixes in browser compatibility and heuristics.
-
-[c++ 0x]: http://ru.wikipedia.org/wiki/C%2B%2B0x
-[html 5]: http://en.wikipedia.org/wiki/HTML5
-[ik]: http://kalnitsky.org.ua/
-
-### For developers
-
-The most significant change is the ability to include language submodes right
-under `contains` instead of defining explicit named submodes in the main array:
-
-    contains: [
-      'string',
-      'number',
-      {begin: '\\n', end: hljs.IMMEDIATE_RE}
-    ]
-
-This is useful for auxiliary modes needed only in one place to define parsing.
-Note that such modes often don't have `className` and hence won't generate a
-separate `` in the resulting markup. This is similar in effect to
-`noMarkup: true`. All existing languages have been refactored accordingly.
-
-Test file test.html has at last become a real test. Now it not only puts the
-detected language name under the code snippet but also tests if it matches the
-expected one. Test summary is displayed right above all language snippets.
-
-
-## CDN
-
-Fine people at [Yandex][] agreed to host highlight.js on their big fast servers.
-[Link up][l]!
-
-[yandex]: http://yandex.com/
-[l]: http://softwaremaniacs.org/soft/highlight/en/download/
-
-
-## Version 5.10 — "Paris".
-
-Though I'm on a vacation in Paris, I decided to release a new version with a
-couple of small fixes:
-
-- Tomas Vitvar discovered that TAB replacement doesn't always work when used
-  with custom markup in code
-- SQL parsing is even more rigid now and doesn't step over SmallTalk in tests
-
-
-## Version 5.9
-
-A long-awaited version is finally released.
-
-New languages:
-
-- Andrew Fedorov made a definition for Lua
-- a long-time highlight.js contributor [Peter Leonov][pl] made a definition for
-  Nginx config
-- [Vladimir Moskva][vm] made a definition for TeX
-
-[pl]: http://kung-fu-tzu.ru/
-[vm]: http://fulc.ru/
-
-Fixes for existing languages:
-
-- [Loren Segal][ls] reworked the Ruby definition and added highlighting for
-  [YARD][] inline documentation
-- the definition of SQL has become more solid and now it shouldn't be overly
-  greedy when it comes to language detection
-
-[ls]: http://gnuu.org/
-[yard]: http://yardoc.org/
-
-The highlighter has become more usable as a library allowing to do highlighting
-from initialization code of JS frameworks and in ajax methods (see.
-readme.eng.txt).
-
-Also this version drops support for the [WordPress][wp] plugin. Everyone is
-welcome to [pick up its maintenance][p] if needed.
-
-[wp]: http://wordpress.org/
-[p]: http://bazaar.launchpad.net/~isagalaev/+junk/highlight/annotate/342/src/wp_highlight.js.php
-
-
-## Version 5.8
-
-- Jan Berkel has contributed a definition for Scala. +1 to hotness!
-- All CSS-styles are rewritten to work only inside `
` tags to avoid
-  conflicts with host site styles.
-
-
-## Version 5.7.
-
-Fixed escaping of quotes in VBScript strings.
-
-
-## Version 5.5
-
-This version brings a small change: now .ini-files allow digits, underscores and
-square brackets in key names.
-
-
-## Version 5.4
-
-Fixed small but upsetting bug in the packer which caused incorrect highlighting
-of explicitly specified languages. Thanks to Andrew Fedorov for precise
-diagnostics!
-
-
-## Version 5.3
-
-The version to fulfil old promises.
-
-The most significant change is that highlight.js now preserves custom user
-markup in code along with its own highlighting markup. This means that now it's
-possible to use, say, links in code. Thanks to [Vladimir Dolzhenko][vd] for the
-[initial proposal][1] and for making a proof-of-concept patch.
-
-Also in this version:
-
-- [Vasily Polovnyov][vp] has sent a GitHub-like style and has implemented
-  support for CSS @-rules and Ruby symbols.
-- Yura Zaripov has sent two styles: Brown Paper and School Book.
-- Oleg Volchkov has sent a definition for [Parser 3][p3].
-
-[1]: http://softwaremaniacs.org/forum/highlightjs/6612/
-[p3]: http://www.parser.ru/
-[vp]: http://vasily.polovnyov.ru/
-[vd]: http://dolzhenko.blogspot.com/
-
-
-## Version 5.2
-
-- at last it's possible to replace indentation TABs with something sensible
-  (e.g. 2 or 4 spaces)
-- new keywords and built-ins for 1C by Sergey Baranov
-- a couple of small fixes to Apache highlighting
-
-
-## Version 5.1
-
-This is one of those nice version consisting entirely of new and shiny
-contributions!
-
-- [Vladimir Ermakov][vooon] created highlighting for AVR Assembler
-- [Ruslan Keba][rukeba] created highlighting for Apache config file. Also his
-  original visual style for it is now available for all highlight.js languages
-  under the name "Magula".
-- [Shuen-Huei Guan][drake] (aka Drake) sent new keywords for RenderMan
-  languages. Also thanks go to [Konstantin Evdokimenko][ke] for his advice on
-  the matter.
-
-[vooon]: http://vehq.ru/about/
-[rukeba]: http://rukeba.com/
-[drake]: http://drakeguan.org/
-[ke]: http://k-evdokimenko.moikrug.ru/
-
-
-## Version 5.0
-
-The main change in the new major version of highlight.js is a mechanism for
-packing several languages along with the library itself into a single compressed
-file. Now sites using several languages will load considerably faster because
-the library won't dynamically include additional files while loading.
-
-Also this version fixes a long-standing bug with Javascript highlighting that
-couldn't distinguish between regular expressions and division operations.
-
-And as usually there were a couple of minor correctness fixes.
-
-Great thanks to all contributors! Keep using highlight.js.
-
-
-## Version 4.3
-
-This version comes with two contributions from [Jason Diamond][jd]:
-
-- language definition for C# (yes! it was a long-missed thing!)
-- Visual Studio-like highlighting style
-
-Plus there are a couple of minor bug fixes for parsing HTML and XML attributes.
-
-[jd]: http://jason.diamond.name/weblog/
-
-
-## Version 4.2
-
-The biggest news is highlighting for Lisp, courtesy of Vasily Polovnyov. It's
-somewhat experimental meaning that for highlighting "keywords" it doesn't use
-any pre-defined set of a Lisp dialect. Instead it tries to highlight first word
-in parentheses wherever it makes sense. I'd like to ask people programming in
-Lisp to confirm if it's a good idea and send feedback to [the forum][f].
-
-Other changes:
-
-- Smalltalk was excluded from DEFAULT_LANGUAGES to save traffic
-- [Vladimir Epifanov][voldmar] has implemented javascript style switcher for
-  test.html
-- comments now allowed inside Ruby function definition
-- [MEL][] language from [Shuen-Huei Guan][drake]
-- whitespace now allowed between `
` and ``
-- better auto-detection of C++ and PHP
-- HTML allows embedded VBScript (`<% .. %>`)
-
-[f]: http://softwaremaniacs.org/forum/highlightjs/
-[voldmar]: http://voldmar.ya.ru/
-[mel]: http://en.wikipedia.org/wiki/Maya_Embedded_Language
-[drake]: http://drakeguan.org/
-
-
-## Version 4.1
-
-Languages:
-
-- Bash from Vah
-- DOS bat-files from Alexander Makarov (Sam)
-- Diff files from Vasily Polovnyov
-- Ini files from myself though initial idea was from Sam
-
-Styles:
-
-- Zenburn from Vladimir Epifanov, this is an imitation of a
-  [well-known theme for Vim][zenburn].
-- Ascetic from myself, as a realization of ideals of non-flashy highlighting:
-  just one color in only three gradations :-)
-
-In other news. [One small bug][bug] was fixed, built-in keywords were added for
-Python and C++ which improved auto-detection for the latter (it was shame that
-[my wife's blog][alenacpp] had issues with it from time to time). And lastly
-thanks go to Sam for getting rid of my stylistic comments in code that were
-getting in the way of [JSMin][].
-
-[zenburn]: http://en.wikipedia.org/wiki/Zenburn
-[alenacpp]: http://alenacpp.blogspot.com/
-[bug]: http://softwaremaniacs.org/forum/viewtopic.php?id=1823
-[jsmin]: http://code.google.com/p/jsmin-php/
-
-
-## Version 4.0
-
-New major version is a result of vast refactoring and of many contributions.
-
-Visible new features:
-
-- Highlighting of embedded languages. Currently is implemented highlighting of
-  Javascript and CSS inside HTML.
-- Bundled 5 ready-made style themes!
-
-Invisible new features:
-
-- Highlight.js no longer pollutes global namespace. Only one object and one
-  function for backward compatibility.
-- Performance is further increased by about 15%.
-
-Changing of a major version number caused by a new format of language definition
-files. If you use some third-party language files they should be updated.
-
-
-## Version 3.5
-
-A very nice version in my opinion fixing a number of small bugs and slightly
-increased speed in a couple of corner cases. Thanks to everybody who reports
-bugs in he [forum][f] and by email!
-
-There is also a new language — XML. A custom XML formerly was detected as HTML
-and didn't highlight custom tags. In this version I tried to make custom XML to
-be detected and highlighted by its own rules. Which by the way include such
-things as CDATA sections and processing instructions (``).
-
-[f]: http://softwaremaniacs.org/forum/viewforum.php?id=6
-
-
-## Version 3.3
-
-[Vladimir Gubarkov][xonix] has provided an interesting and useful addition.
-File export.html contains a little program that shows and allows to copy and
-paste an HTML code generated by the highlighter for any code snippet. This can
-be useful in situations when one can't use the script itself on a site.
-
-
-[xonix]: http://xonixx.blogspot.com/
-
-
-## Version 3.2 consists completely of contributions:
-
-- Vladimir Gubarkov has described SmallTalk
-- Yuri Ivanov has described 1C
-- Peter Leonov has packaged the highlighter as a Firefox extension
-- Vladimir Ermakov has compiled a mod for phpBB
-
-Many thanks to you all!
-
-
-## Version 3.1
-
-Three new languages are available: Django templates, SQL and Axapta. The latter
-two are sent by [Dmitri Roudakov][1]. However I've almost entirely rewrote an
-SQL definition but I'd never started it be it from the ground up :-)
-
-The engine itself has got a long awaited feature of grouping keywords
-("keyword", "built-in function", "literal"). No more hacks!
-
-[1]: http://roudakov.ru/
-
-
-## Version 3.0
-
-It is major mainly because now highlight.js has grown large and has become
-modular. Now when you pass it a list of languages to highlight it will
-dynamically load into a browser only those languages.
-
-Also:
-
-- Konstantin Evdokimenko of [RibKit][] project has created a highlighting for
-  RenderMan Shading Language and RenderMan Interface Bytestream. Yay for more
-  languages!
-- Heuristics for C++ and HTML got better.
-- I've implemented (at last) a correct handling of backslash escapes in C-like
-  languages.
-
-There is also a small backwards incompatible change in the new version. The
-function initHighlighting that was used to initialize highlighting instead of
-initHighlightingOnLoad a long time ago no longer works. If you by chance still
-use it — replace it with the new one.
-
-[RibKit]: http://ribkit.sourceforge.net/
-
-
-## Version 2.9
-
-Highlight.js is a parser, not just a couple of regular expressions. That said
-I'm glad to announce that in the new version 2.9 has support for:
-
-- in-string substitutions for Ruby -- `#{...}`
-- strings from from numeric symbol codes (like #XX) for Delphi
-
-
-## Version 2.8
-
-A maintenance release with more tuned heuristics. Fully backwards compatible.
-
-
-## Version 2.7
-
-- Nikita Ledyaev presents highlighting for VBScript, yay!
-- A couple of bugs with escaping in strings were fixed thanks to Mickle
-- Ongoing tuning of heuristics
-
-Fixed bugs were rather unpleasant so I encourage everyone to upgrade!
-
-
-## Version 2.4
-
-- Peter Leonov provides another improved highlighting for Perl
-- Javascript gets a new kind of keywords — "literals". These are the words
-  "true", "false" and "null"
-
-Also highlight.js homepage now lists sites that use the library. Feel free to
-add your site by [dropping me a message][mail] until I find the time to build a
-submit form.
-
-[mail]: mailto:Maniac@SoftwareManiacs.Org
-
-
-## Version 2.3
-
-This version fixes IE breakage in previous version. My apologies to all who have
-already downloaded that one!
-
-
-## Version 2.2
-
-- added highlighting for Javascript
-- at last fixed parsing of Delphi's escaped apostrophes in strings
-- in Ruby fixed highlighting of keywords 'def' and 'class', same for 'sub' in
-  Perl
-
-
-## Version 2.0
-
-- Ruby support by [Anton Kovalyov][ak]
-- speed increased by orders of magnitude due to new way of parsing
-- this same way allows now correct highlighting of keywords in some tricky
-  places (like keyword "End" at the end of Delphi classes)
-
-[ak]: http://anton.kovalyov.net/
-
-
-## Version 1.0
-
-Version 1.0 of javascript syntax highlighter is released!
-
-It's the first version available with English description. Feel free to post
-your comments and question to [highlight.js forum][forum]. And don't be afraid
-if you find there some fancy Cyrillic letters -- it's for Russian users too :-)
-
-[forum]: http://softwaremaniacs.org/forum/viewforum.php?id=6
diff --git a/doc/html-manual/highlight/LICENSE b/doc/html-manual/highlight/LICENSE
deleted file mode 100644
index 422deb7350..0000000000
--- a/doc/html-manual/highlight/LICENSE
+++ /dev/null
@@ -1,24 +0,0 @@
-Copyright (c) 2006, Ivan Sagalaev
-All rights reserved.
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-    * Redistributions of source code must retain the above copyright
-      notice, this list of conditions and the following disclaimer.
-    * Redistributions in binary form must reproduce the above copyright
-      notice, this list of conditions and the following disclaimer in the
-      documentation and/or other materials provided with the distribution.
-    * Neither the name of highlight.js nor the names of its contributors 
-      may be used to endorse or promote products derived from this software 
-      without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY
-EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY
-DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
-(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
-LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
-ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
-SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/doc/html-manual/highlight/README.md b/doc/html-manual/highlight/README.md
deleted file mode 100644
index 9f76e6bd56..0000000000
--- a/doc/html-manual/highlight/README.md
+++ /dev/null
@@ -1,150 +0,0 @@
-# Highlight.js
-
-[![Build Status](https://travis-ci.org/isagalaev/highlight.js.svg?branch=master)](https://travis-ci.org/isagalaev/highlight.js)
-
-Highlight.js is a syntax highlighter written in JavaScript. It works in
-the browser as well as on the server. It works with pretty much any
-markup, doesn’t depend on any framework and has automatic language
-detection.
-
-## Getting Started
-
-The bare minimum for using highlight.js on a web page is linking to the
-library along with one of the styles and calling
-[`initHighlightingOnLoad`][1]:
-
-```html
-
-
-
-```
-
-This will find and highlight code inside of `
` tags; it tries
-to detect the language automatically. If automatic detection doesn’t
-work for you, you can specify the language in the `class` attribute:
-
-```html
-
...

-```
-
-The list of supported language classes is available in the [class
-reference][2].  Classes can also be prefixed with either `language-` or
-`lang-`.
-
-To disable highlighting altogether use the `nohighlight` class:
-
-```html
-
...

-```
-
-## Custom Initialization
-
-When you need a bit more control over the initialization of
-highlight.js, you can use the [`highlightBlock`][3] and [`configure`][4]
-functions. This allows you to control *what* to highlight and *when*.
-
-Here’s an equivalent way to calling [`initHighlightingOnLoad`][1] using
-jQuery:
-
-```javascript
-$(document).ready(function() {
-  $('pre code').each(function(i, block) {
-    hljs.highlightBlock(block);
-  });
-});
-```
-
-You can use any tags instead of `
` to mark up your code. If
-you don't use a container that preserve line breaks you will need to
-configure highlight.js to use the `
` tag:
-
-```javascript
-hljs.configure({useBR: true});
-
-$('div.code').each(function(i, block) {
-  hljs.highlightBlock(block);
-});
-```
-
-For other options refer to the documentation for [`configure`][4].
-
-
-## Web Workers
-
-You can run highlighting inside a web worker to avoid freezing the browser
-window while dealing with very big chunks of code.
-
-In your main script:
-
-```javascript
-addEventListener('load', function() {
-  var code = document.querySelector('#code');
-  var worker = new Worker('worker.js');
-  worker.onmessage = function(event) { code.innerHTML = event.data; }
-  worker.postMessage(code.textContent);
-})
-```
-
-In worker.js:
-
-```javascript
-onmessage = function(event) {
-  importScripts('/highlight.pack.js');
-  var result = self.hljs.highlightAuto(event.data);
-  postMessage(result.value);
-}
-```
-
-
-## Getting the Library
-
-You can get highlight.js as a hosted, or custom-build, browser script or
-as a server module. Right out of the box the browser script supports
-both AMD and CommonJS, so if you wish you can use RequireJS or
-Browserify without having to build from source. The server module also
-works perfectly fine with Browserify, but there is the option to use a
-build specific to browsers rather than something meant for a server.
-Head over to the [download page][5] for all the options.
-
-**Don't link to GitHub directly.** The library is not supposed to work straight
-from the source, it requires building. If none of the pre-packaged options
-work for you refer to the [building documentation][6].
-
-**The CDN-hosted package doesn't have all the languages.** Otherwise it'd be
-too big. If you don't see the language you need in the ["Common" section][5],
-it can be added manually:
-
-```html
-
-```
-
-**On Almond.** You need to use the optimizer to give the module a name. For
-example:
-
-```
-r.js -o name=hljs paths.hljs=/path/to/highlight out=highlight.js
-```
-
-
-## License
-
-Highlight.js is released under the BSD License. See [LICENSE][7] file
-for details.
-
-## Links
-
-The official site for the library is at .
-
-Further in-depth documentation for the API and other topics is at
-.
-
-Authors and contributors are listed in the [AUTHORS.en.txt][8] file.
-
-[1]: http://highlightjs.readthedocs.io/en/latest/api.html#inithighlightingonload
-[2]: http://highlightjs.readthedocs.io/en/latest/css-classes-reference.html
-[3]: http://highlightjs.readthedocs.io/en/latest/api.html#highlightblock-block
-[4]: http://highlightjs.readthedocs.io/en/latest/api.html#configure-options
-[5]: https://highlightjs.org/download/
-[6]: http://highlightjs.readthedocs.io/en/latest/building-testing.html
-[7]: https://github.com/isagalaev/highlight.js/blob/master/LICENSE
-[8]: https://github.com/isagalaev/highlight.js/blob/master/AUTHORS.en.txt
diff --git a/doc/html-manual/highlight/README.ru.md b/doc/html-manual/highlight/README.ru.md
deleted file mode 100644
index ac481d0718..0000000000
--- a/doc/html-manual/highlight/README.ru.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Highlight.js
-
-Highlight.js — это инструмент для подсветки синтаксиса, написанный на JavaScript. Он работает
-и в браузере, и на сервере. Он работает с практически любой HTML разметкой, не
-зависит от каких-либо фреймворков и умеет автоматически определять язык.
-
-
-## Начало работы
-
-Минимум, что нужно сделать для использования highlight.js на веб-странице — это
-подключить библиотеку, CSS-стили и вызывать [`initHighlightingOnLoad`][1]:
-
-```html
-
-
-
-```
-
-Библиотека найдёт и раскрасит код внутри тегов `
`, попытавшись
-автоматически определить язык. Когда автоопределение не срабатывает, можно явно
-указать язык в атрибуте class:
-
-```html
-
...

-```
-
-Список поддерживаемых классов языков доступен в [справочнике по классам][2].
-Класс также можно предварить префиксами `language-` или `lang-`.
-
-Чтобы отключить подсветку для какого-то блока, используйте класс `nohighlight`:
-
-```html
-
...

-```
-
-## Инициализация вручную
-
-Чтобы иметь чуть больше контроля за инициализацией подсветки, вы можете
-использовать функции [`highlightBlock`][3] и [`configure`][4]. Таким образом
-можно управлять тем, *что* и *когда* подсвечивать.
-
-Вот пример инициализации, эквивалентной вызову [`initHighlightingOnLoad`][1], но
-с использованием jQuery:
-
-```javascript
-$(document).ready(function() {
-  $('pre code').each(function(i, block) {
-    hljs.highlightBlock(block);
-  });
-});
-```
-
-Вы можете использовать любые теги разметки вместо `
`. Если
-используете контейнер, не сохраняющий переводы строк, вам нужно сказать
-highlight.js использовать для них тег `
`:
-
-```javascript
-hljs.configure({useBR: true});
-
-$('div.code').each(function(i, block) {
-  hljs.highlightBlock(block);
-});
-```
-
-Другие опции можно найти в документации функции [`configure`][4].
-
-
-## Web Workers
-
-Подсветку можно запустить внутри web worker'а, чтобы окно
-браузера не подтормаживало при работе с большими кусками кода.
-
-В основном скрипте:
-
-```javascript
-addEventListener('load', function() {
-  var code = document.querySelector('#code');
-  var worker = new Worker('worker.js');
-  worker.onmessage = function(event) { code.innerHTML = event.data; }
-  worker.postMessage(code.textContent);
-})
-```
-
-В worker.js:
-
-```javascript
-onmessage = function(event) {
-  importScripts('/highlight.pack.js');
-  var result = self.hljs.highlightAuto(event.data);
-  postMessage(result.value);
-}
-```
-
-
-## Установка библиотеки
-
-Highlight.js можно использовать в браузере прямо с CDN хостинга или скачать
-индивидуальную сборку, а также установив модуль на сервере. На
-[странице загрузки][5] подробно описаны все варианты.
-
-**Не подключайте GitHub напрямую.** Библиотека не предназначена для
-использования в виде исходного кода, а требует отдельной сборки. Если вам не
-подходит ни один из готовых вариантов, читайте [документацию по сборке][6].
-
-**Файл на CDN содержит не все языки.** Иначе он будет слишком большого размера.
-Если нужного вам языка нет в [категории "Common"][5], можно дообавить его
-вручную:
-
-```html
-
-```
-
-**Про Almond.** Нужно задать имя модуля в оптимизаторе, например:
-
-```
-r.js -o name=hljs paths.hljs=/path/to/highlight out=highlight.js
-```
-
-
-## Лицензия
-
-Highlight.js распространяется под лицензией BSD. Подробнее читайте файл
-[LICENSE][7].
-
-
-## Ссылки
-
-Официальный сайт билиотеки расположен по адресу .
-
-Более подробная документация по API и другим темам расположена на
-.
-
-Авторы и контрибьюторы перечислены в файле [AUTHORS.ru.txt][8] file.
-
-[1]: http://highlightjs.readthedocs.io/en/latest/api.html#inithighlightingonload
-[2]: http://highlightjs.readthedocs.io/en/latest/css-classes-reference.html
-[3]: http://highlightjs.readthedocs.io/en/latest/api.html#highlightblock-block
-[4]: http://highlightjs.readthedocs.io/en/latest/api.html#configure-options
-[5]: https://highlightjs.org/download/
-[6]: http://highlightjs.readthedocs.io/en/latest/building-testing.html
-[7]: https://github.com/isagalaev/highlight.js/blob/master/LICENSE
-[8]: https://github.com/isagalaev/highlight.js/blob/master/AUTHORS.ru.txt
diff --git a/doc/html-manual/highlight/highlight.pack.js b/doc/html-manual/highlight/highlight.pack.js
deleted file mode 100644
index e93b5ee1ce..0000000000
--- a/doc/html-manual/highlight/highlight.pack.js
+++ /dev/null
@@ -1,2 +0,0 @@
-/*! highlight.js v9.11.0 | BSD3 License | git.io/hljslicense */
-!function(e){var n="object"==typeof window&&window||"object"==typeof self&&self;"undefined"!=typeof exports?e(exports):n&&(n.hljs=e({}),"function"==typeof define&&define.amd&&define([],function(){return n.hljs}))}(function(e){function n(e){return e.replace(/&/g,"&").replace(//g,">")}function t(e){return e.nodeName.toLowerCase()}function r(e,n){var t=e&&e.exec(n);return t&&0===t.index}function a(e){return k.test(e)}function i(e){var n,t,r,i,o=e.className+" ";if(o+=e.parentNode?e.parentNode.className:"",t=B.exec(o))return w(t[1])?t[1]:"no-highlight";for(o=o.split(/\s+/),n=0,r=o.length;r>n;n++)if(i=o[n],a(i)||w(i))return i}function o(e){var n,t={},r=Array.prototype.slice.call(arguments,1);for(n in e)t[n]=e[n];return r.forEach(function(e){for(n in e)t[n]=e[n]}),t}function u(e){var n=[];return function r(e,a){for(var i=e.firstChild;i;i=i.nextSibling)3===i.nodeType?a+=i.nodeValue.length:1===i.nodeType&&(n.push({event:"start",offset:a,node:i}),a=r(i,a),t(i).match(/br|hr|img|input/)||n.push({event:"stop",offset:a,node:i}));return a}(e,0),n}function c(e,r,a){function i(){return e.length&&r.length?e[0].offset!==r[0].offset?e[0].offset"}function u(e){s+=""}function c(e){("start"===e.event?o:u)(e.node)}for(var l=0,s="",f=[];e.length||r.length;){var g=i();if(s+=n(a.substring(l,g[0].offset)),l=g[0].offset,g===e){f.reverse().forEach(u);do c(g.splice(0,1)[0]),g=i();while(g===e&&g.length&&g[0].offset===l);f.reverse().forEach(o)}else"start"===g[0].event?f.push(g[0].node):f.pop(),c(g.splice(0,1)[0])}return s+n(a.substr(l))}function l(e){return e.v&&!e.cached_variants&&(e.cached_variants=e.v.map(function(n){return o(e,{v:null},n)})),e.cached_variants||e.eW&&[o(e)]||[e]}function s(e){function n(e){return e&&e.source||e}function t(t,r){return new RegExp(n(t),"m"+(e.cI?"i":"")+(r?"g":""))}function r(a,i){if(!a.compiled){if(a.compiled=!0,a.k=a.k||a.bK,a.k){var o={},u=function(n,t){e.cI&&(t=t.toLowerCase()),t.split(" ").forEach(function(e){var t=e.split("|");o[t[0]]=[n,t[1]?Number(t[1]):1]})};"string"==typeof a.k?u("keyword",a.k):x(a.k).forEach(function(e){u(e,a.k[e])}),a.k=o}a.lR=t(a.l||/\w+/,!0),i&&(a.bK&&(a.b="\\b("+a.bK.split(" ").join("|")+")\\b"),a.b||(a.b=/\B|\b/),a.bR=t(a.b),a.e||a.eW||(a.e=/\B|\b/),a.e&&(a.eR=t(a.e)),a.tE=n(a.e)||"",a.eW&&i.tE&&(a.tE+=(a.e?"|":"")+i.tE)),a.i&&(a.iR=t(a.i)),null==a.r&&(a.r=1),a.c||(a.c=[]),a.c=Array.prototype.concat.apply([],a.c.map(function(e){return l("self"===e?a:e)})),a.c.forEach(function(e){r(e,a)}),a.starts&&r(a.starts,i);var c=a.c.map(function(e){return e.bK?"\\.?("+e.b+")\\.?":e.b}).concat([a.tE,a.i]).map(n).filter(Boolean);a.t=c.length?t(c.join("|"),!0):{exec:function(){return null}}}}r(e)}function f(e,t,a,i){function o(e,n){var t,a;for(t=0,a=n.c.length;a>t;t++)if(r(n.c[t].bR,e))return n.c[t]}function u(e,n){if(r(e.eR,n)){for(;e.endsParent&&e.parent;)e=e.parent;return e}return e.eW?u(e.parent,n):void 0}function c(e,n){return!a&&r(n.iR,e)}function l(e,n){var t=N.cI?n[0].toLowerCase():n[0];return e.k.hasOwnProperty(t)&&e.k[t]}function p(e,n,t,r){var a=r?"":I.classPrefix,i='',i+n+o}function h(){var e,t,r,a;if(!E.k)return n(k);for(a="",t=0,E.lR.lastIndex=0,r=E.lR.exec(k);r;)a+=n(k.substring(t,r.index)),e=l(E,r),e?(B+=e[1],a+=p(e[0],n(r[0]))):a+=n(r[0]),t=E.lR.lastIndex,r=E.lR.exec(k);return a+n(k.substr(t))}function d(){var e="string"==typeof E.sL;if(e&&!y[E.sL])return n(k);var t=e?f(E.sL,k,!0,x[E.sL]):g(k,E.sL.length?E.sL:void 0);return E.r>0&&(B+=t.r),e&&(x[E.sL]=t.top),p(t.language,t.value,!1,!0)}function b(){L+=null!=E.sL?d():h(),k=""}function v(e){L+=e.cN?p(e.cN,"",!0):"",E=Object.create(e,{parent:{value:E}})}function m(e,n){if(k+=e,null==n)return b(),0;var t=o(n,E);if(t)return t.skip?k+=n:(t.eB&&(k+=n),b(),t.rB||t.eB||(k=n)),v(t,n),t.rB?0:n.length;var r=u(E,n);if(r){var a=E;a.skip?k+=n:(a.rE||a.eE||(k+=n),b(),a.eE&&(k=n));do E.cN&&(L+=C),E.skip||(B+=E.r),E=E.parent;while(E!==r.parent);return r.starts&&v(r.starts,""),a.rE?0:n.length}if(c(n,E))throw new Error('Illegal lexeme "'+n+'" for mode "'+(E.cN||"")+'"');return k+=n,n.length||1}var N=w(e);if(!N)throw new Error('Unknown language: "'+e+'"');s(N);var R,E=i||N,x={},L="";for(R=E;R!==N;R=R.parent)R.cN&&(L=p(R.cN,"",!0)+L);var k="",B=0;try{for(var M,j,O=0;;){if(E.t.lastIndex=O,M=E.t.exec(t),!M)break;j=m(t.substring(O,M.index),M[0]),O=M.index+j}for(m(t.substr(O)),R=E;R.parent;R=R.parent)R.cN&&(L+=C);return{r:B,value:L,language:e,top:E}}catch(T){if(T.message&&-1!==T.message.indexOf("Illegal"))return{r:0,value:n(t)};throw T}}function g(e,t){t=t||I.languages||x(y);var r={r:0,value:n(e)},a=r;return t.filter(w).forEach(function(n){var t=f(n,e,!1);t.language=n,t.r>a.r&&(a=t),t.r>r.r&&(a=r,r=t)}),a.language&&(r.second_best=a),r}function p(e){return I.tabReplace||I.useBR?e.replace(M,function(e,n){return I.useBR&&"\n"===e?"
":I.tabReplace?n.replace(/\t/g,I.tabReplace):""}):e}function h(e,n,t){var r=n?L[n]:t,a=[e.trim()];return e.match(/\bhljs\b/)||a.push("hljs"),-1===e.indexOf(r)&&a.push(r),a.join(" ").trim()}function d(e){var n,t,r,o,l,s=i(e);a(s)||(I.useBR?(n=document.createElementNS("http://www.w3.org/1999/xhtml","div"),n.innerHTML=e.innerHTML.replace(/\n/g,"").replace(//g,"\n")):n=e,l=n.textContent,r=s?f(s,l,!0):g(l),t=u(n),t.length&&(o=document.createElementNS("http://www.w3.org/1999/xhtml","div"),o.innerHTML=r.value,r.value=c(t,u(o),l)),r.value=p(r.value),e.innerHTML=r.value,e.className=h(e.className,s,r.language),e.result={language:r.language,re:r.r},r.second_best&&(e.second_best={language:r.second_best.language,re:r.second_best.r}))}function b(e){I=o(I,e)}function v(){if(!v.called){v.called=!0;var e=document.querySelectorAll("pre code");E.forEach.call(e,d)}}function m(){addEventListener("DOMContentLoaded",v,!1),addEventListener("load",v,!1)}function N(n,t){var r=y[n]=t(e);r.aliases&&r.aliases.forEach(function(e){L[e]=n})}function R(){return x(y)}function w(e){return e=(e||"").toLowerCase(),y[e]||y[L[e]]}var E=[],x=Object.keys,y={},L={},k=/^(no-?highlight|plain|text)$/i,B=/\blang(?:uage)?-([\w-]+)\b/i,M=/((^(<[^>]+>|\t|)+|(?:\n)))/gm,C="",I={classPrefix:"hljs-",tabReplace:null,useBR:!1,languages:void 0};return e.highlight=f,e.highlightAuto=g,e.fixMarkup=p,e.highlightBlock=d,e.configure=b,e.initHighlighting=v,e.initHighlightingOnLoad=m,e.registerLanguage=N,e.listLanguages=R,e.getLanguage=w,e.inherit=o,e.IR="[a-zA-Z]\\w*",e.UIR="[a-zA-Z_]\\w*",e.NR="\\b\\d+(\\.\\d+)?",e.CNR="(-?)(\\b0[xX][a-fA-F0-9]+|(\\b\\d+(\\.\\d*)?|\\.\\d+)([eE][-+]?\\d+)?)",e.BNR="\\b(0b[01]+)",e.RSR="!|!=|!==|%|%=|&|&&|&=|\\*|\\*=|\\+|\\+=|,|-|-=|/=|/|:|;|<<|<<=|<=|<|===|==|=|>>>=|>>=|>=|>>>|>>|>|\\?|\\[|\\{|\\(|\\^|\\^=|\\||\\|=|\\|\\||~",e.BE={b:"\\\\[\\s\\S]",r:0},e.ASM={cN:"string",b:"'",e:"'",i:"\\n",c:[e.BE]},e.QSM={cN:"string",b:'"',e:'"',i:"\\n",c:[e.BE]},e.PWM={b:/\b(a|an|the|are|I'm|isn't|don't|doesn't|won't|but|just|should|pretty|simply|enough|gonna|going|wtf|so|such|will|you|your|they|like|more)\b/},e.C=function(n,t,r){var a=e.inherit({cN:"comment",b:n,e:t,c:[]},r||{});return a.c.push(e.PWM),a.c.push({cN:"doctag",b:"(?:TODO|FIXME|NOTE|BUG|XXX):",r:0}),a},e.CLCM=e.C("//","$"),e.CBCM=e.C("/\\*","\\*/"),e.HCM=e.C("#","$"),e.NM={cN:"number",b:e.NR,r:0},e.CNM={cN:"number",b:e.CNR,r:0},e.BNM={cN:"number",b:e.BNR,r:0},e.CSSNM={cN:"number",b:e.NR+"(%|em|ex|ch|rem|vw|vh|vmin|vmax|cm|mm|in|pt|pc|px|deg|grad|rad|turn|s|ms|Hz|kHz|dpi|dpcm|dppx)?",r:0},e.RM={cN:"regexp",b:/\//,e:/\/[gimuy]*/,i:/\n/,c:[e.BE,{b:/\[/,e:/\]/,r:0,c:[e.BE]}]},e.TM={cN:"title",b:e.IR,r:0},e.UTM={cN:"title",b:e.UIR,r:0},e.METHOD_GUARD={b:"\\.\\s*"+e.UIR,r:0},e});hljs.registerLanguage("verilog",function(e){var n={keyword:"accept_on alias always always_comb always_ff always_latch and assert assign assume automatic before begin bind bins binsof bit break buf|0 bufif0 bufif1 byte case casex casez cell chandle checker class clocking cmos config const constraint context continue cover covergroup coverpoint cross deassign default defparam design disable dist do edge else end endcase endchecker endclass endclocking endconfig endfunction endgenerate endgroup endinterface endmodule endpackage endprimitive endprogram endproperty endspecify endsequence endtable endtask enum event eventually expect export extends extern final first_match for force foreach forever fork forkjoin function generate|5 genvar global highz0 highz1 if iff ifnone ignore_bins illegal_bins implements implies import incdir include initial inout input inside instance int integer interconnect interface intersect join join_any join_none large let liblist library local localparam logic longint macromodule matches medium modport module nand negedge nettype new nexttime nmos nor noshowcancelled not notif0 notif1 or output package packed parameter pmos posedge primitive priority program property protected pull0 pull1 pulldown pullup pulsestyle_ondetect pulsestyle_onevent pure rand randc randcase randsequence rcmos real realtime ref reg reject_on release repeat restrict return rnmos rpmos rtran rtranif0 rtranif1 s_always s_eventually s_nexttime s_until s_until_with scalared sequence shortint shortreal showcancelled signed small soft solve specify specparam static string strong strong0 strong1 struct super supply0 supply1 sync_accept_on sync_reject_on table tagged task this throughout time timeprecision timeunit tran tranif0 tranif1 tri tri0 tri1 triand trior trireg type typedef union unique unique0 unsigned until until_with untyped use uwire var vectored virtual void wait wait_order wand weak weak0 weak1 while wildcard wire with within wor xnor xor",literal:"null",built_in:"$finish $stop $exit $fatal $error $warning $info $realtime $time $printtimescale $bitstoreal $bitstoshortreal $itor $signed $cast $bits $stime $timeformat $realtobits $shortrealtobits $rtoi $unsigned $asserton $assertkill $assertpasson $assertfailon $assertnonvacuouson $assertoff $assertcontrol $assertpassoff $assertfailoff $assertvacuousoff $isunbounded $sampled $fell $changed $past_gclk $fell_gclk $changed_gclk $rising_gclk $steady_gclk $coverage_control $coverage_get $coverage_save $set_coverage_db_name $rose $stable $past $rose_gclk $stable_gclk $future_gclk $falling_gclk $changing_gclk $display $coverage_get_max $coverage_merge $get_coverage $load_coverage_db $typename $unpacked_dimensions $left $low $increment $clog2 $ln $log10 $exp $sqrt $pow $floor $ceil $sin $cos $tan $countbits $onehot $isunknown $fatal $warning $dimensions $right $high $size $asin $acos $atan $atan2 $hypot $sinh $cosh $tanh $asinh $acosh $atanh $countones $onehot0 $error $info $random $dist_chi_square $dist_erlang $dist_exponential $dist_normal $dist_poisson $dist_t $dist_uniform $q_initialize $q_remove $q_exam $async$and$array $async$nand$array $async$or$array $async$nor$array $sync$and$array $sync$nand$array $sync$or$array $sync$nor$array $q_add $q_full $psprintf $async$and$plane $async$nand$plane $async$or$plane $async$nor$plane $sync$and$plane $sync$nand$plane $sync$or$plane $sync$nor$plane $system $display $displayb $displayh $displayo $strobe $strobeb $strobeh $strobeo $write $readmemb $readmemh $writememh $value$plusargs $dumpvars $dumpon $dumplimit $dumpports $dumpportson $dumpportslimit $writeb $writeh $writeo $monitor $monitorb $monitorh $monitoro $writememb $dumpfile $dumpoff $dumpall $dumpflush $dumpportsoff $dumpportsall $dumpportsflush $fclose $fdisplay $fdisplayb $fdisplayh $fdisplayo $fstrobe $fstrobeb $fstrobeh $fstrobeo $swrite $swriteb $swriteh $swriteo $fscanf $fread $fseek $fflush $feof $fopen $fwrite $fwriteb $fwriteh $fwriteo $fmonitor $fmonitorb $fmonitorh $fmonitoro $sformat $sformatf $fgetc $ungetc $fgets $sscanf $rewind $ftell $ferror"};return{aliases:["v","sv","svh"],cI:!1,k:n,l:/[\w\$]+/,c:[e.CBCM,e.CLCM,e.QSM,{cN:"number",c:[e.BE],v:[{b:"\\b((\\d+'(b|h|o|d|B|H|O|D))[0-9xzXZa-fA-F_]+)"},{b:"\\B(('(b|h|o|d|B|H|O|D))[0-9xzXZa-fA-F_]+)"},{b:"\\b([0-9_])+",r:0}]},{cN:"variable",v:[{b:"#\\((?!parameter).+\\)"},{b:"\\.\\w+",r:0}]},{cN:"meta",b:"`",e:"$",k:{"meta-keyword":"define __FILE__ __LINE__ begin_keywords celldefine default_nettype define else elsif end_keywords endcelldefine endif ifdef ifndef include line nounconnected_drive pragma resetall timescale unconnected_drive undef undefineall"},r:0}]}});hljs.registerLanguage("cpp",function(t){var e={cN:"keyword",b:"\\b[a-z\\d_]*_t\\b"},r={cN:"string",v:[{b:'(u8?|U)?L?"',e:'"',i:"\\n",c:[t.BE]},{b:'(u8?|U)?R"',e:'"',c:[t.BE]},{b:"'\\\\?.",e:"'",i:"."}]},s={cN:"number",v:[{b:"\\b(0b[01']+)"},{b:"(-?)\\b([\\d']+(\\.[\\d']*)?|\\.[\\d']+)(u|U|l|L|ul|UL|f|F|b|B)"},{b:"(-?)(\\b0[xX][a-fA-F0-9']+|(\\b[\\d']+(\\.[\\d']*)?|\\.[\\d']+)([eE][-+]?[\\d']+)?)"}],r:0},i={cN:"meta",b:/#\s*[a-z]+\b/,e:/$/,k:{"meta-keyword":"if else elif endif define undef warning error line pragma ifdef ifndef include"},c:[{b:/\\\n/,r:0},t.inherit(r,{cN:"meta-string"}),{cN:"meta-string",b:/<[^\n>]*>/,e:/$/,i:"\\n"},t.CLCM,t.CBCM]},a=t.IR+"\\s*\\(",c={keyword:"int float while private char catch import module export virtual operator sizeof dynamic_cast|10 typedef const_cast|10 const for static_cast|10 union namespace unsigned long volatile static protected bool template mutable if public friend do goto auto void enum else break extern using asm case typeid short reinterpret_cast|10 default double register explicit signed typename try this switch continue inline delete alignof constexpr decltype noexcept static_assert thread_local restrict _Bool complex _Complex _Imaginary atomic_bool atomic_char atomic_schar atomic_uchar atomic_short atomic_ushort atomic_int atomic_uint atomic_long atomic_ulong atomic_llong atomic_ullong new throw return and or not",built_in:"std string cin cout cerr clog stdin stdout stderr stringstream istringstream ostringstream auto_ptr deque list queue stack vector map set bitset multiset multimap unordered_set unordered_map unordered_multiset unordered_multimap array shared_ptr abort abs acos asin atan2 atan calloc ceil cosh cos exit exp fabs floor fmod fprintf fputs free frexp fscanf isalnum isalpha iscntrl isdigit isgraph islower isprint ispunct isspace isupper isxdigit tolower toupper labs ldexp log10 log malloc realloc memchr memcmp memcpy memset modf pow printf putchar puts scanf sinh sin snprintf sprintf sqrt sscanf strcat strchr strcmp strcpy strcspn strlen strncat strncmp strncpy strpbrk strrchr strspn strstr tanh tan vfprintf vprintf vsprintf endl initializer_list unique_ptr",literal:"true false nullptr NULL"},n=[e,t.CLCM,t.CBCM,s,r];return{aliases:["c","cc","h","c++","h++","hpp"],k:c,i:"",k:c,c:["self",e]},{b:t.IR+"::",k:c},{v:[{b:/=/,e:/;/},{b:/\(/,e:/\)/},{bK:"new throw return else",e:/;/}],k:c,c:n.concat([{b:/\(/,e:/\)/,k:c,c:n.concat(["self"]),r:0}]),r:0},{cN:"function",b:"("+t.IR+"[\\*&\\s]+)+"+a,rB:!0,e:/[{;=]/,eE:!0,k:c,i:/[^\w\s\*&]/,c:[{b:a,rB:!0,c:[t.TM],r:0},{cN:"params",b:/\(/,e:/\)/,k:c,r:0,c:[t.CLCM,t.CBCM,r,s,e]},t.CLCM,t.CBCM,i]},{cN:"class",bK:"class struct",e:/[{;:]/,c:[{b://,c:["self"]},t.TM]}]),exports:{preprocessor:i,strings:r,k:c}}});
\ No newline at end of file
diff --git a/doc/html-manual/highlight/styles/agate.css b/doc/html-manual/highlight/styles/agate.css
deleted file mode 100644
index 8d64547c58..0000000000
--- a/doc/html-manual/highlight/styles/agate.css
+++ /dev/null
@@ -1,108 +0,0 @@
-/*!
- * Agate by Taufik Nurrohman 
- * ----------------------------------------------------
- *
- * #ade5fc
- * #a2fca2
- * #c6b4f0
- * #d36363
- * #fcc28c
- * #fc9b9b
- * #ffa
- * #fff
- * #333
- * #62c8f3
- * #888
- *
- */
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #333;
-  color: white;
-}
-
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-code,
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-tag {
-  color: #62c8f3;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ade5fc;
-}
-
-.hljs-string,
-.hljs-bullet {
-  color: #a2fca2;
-}
-
-.hljs-type,
-.hljs-title,
-.hljs-section,
-.hljs-attribute,
-.hljs-quote,
-.hljs-built_in,
-.hljs-builtin-name {
-  color: #ffa;
-}
-
-.hljs-number,
-.hljs-symbol,
-.hljs-bullet {
-  color: #d36363;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal {
-  color: #fcc28c;
-}
-
-.hljs-comment,
-.hljs-deletion,
-.hljs-code {
-  color: #888;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #c6b4f0;
-}
-
-.hljs-meta {
-  color: #fc9b9b;
-}
-
-.hljs-deletion {
-  background-color: #fc9b9b;
-  color: #333;
-}
-
-.hljs-addition {
-  background-color: #a2fca2;
-  color: #333;
-}
-
-.hljs a {
-  color: inherit;
-}
-
-.hljs a:focus,
-.hljs a:hover {
-  color: inherit;
-  text-decoration: underline;
-}
diff --git a/doc/html-manual/highlight/styles/androidstudio.css b/doc/html-manual/highlight/styles/androidstudio.css
deleted file mode 100644
index bc8e473b59..0000000000
--- a/doc/html-manual/highlight/styles/androidstudio.css
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
-Date: 24 Fev 2015
-Author: Pedro Oliveira 
-*/
-
-.hljs {
-  color: #a9b7c6;
-  background: #282b2e;
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-}
-
-.hljs-number,
-.hljs-literal,
-.hljs-symbol,
-.hljs-bullet {
-  color: #6897BB;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-deletion {
-  color: #cc7832;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-link {
-  color: #629755;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #808080;
-}
-
-.hljs-meta {
-  color: #bbb529;
-}
-
-.hljs-string,
-.hljs-attribute,
-.hljs-addition {
-  color: #6A8759;
-}
-
-.hljs-section,
-.hljs-title,
-.hljs-type {
-  color: #ffc66d;
-}
-
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #e8bf6a;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/arduino-light.css b/doc/html-manual/highlight/styles/arduino-light.css
deleted file mode 100644
index 4b8b7fd3c9..0000000000
--- a/doc/html-manual/highlight/styles/arduino-light.css
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
-
-Arduino® Light Theme - Stefania Mellai 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #FFFFFF;
-}
-
-.hljs,
-.hljs-subst {
-  color: #434f54;
-}
-
-.hljs-keyword,
-.hljs-attribute,
-.hljs-selector-tag,
-.hljs-doctag,
-.hljs-name {
-  color: #00979D;
-}
-
-.hljs-built_in,
-.hljs-literal,
-.hljs-bullet,
-.hljs-code,
-.hljs-addition {
-  color: #D35400;
-}
-
-.hljs-regexp,
-.hljs-symbol,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-link,
-.hljs-selector-attr,
-.hljs-selector-pseudo {
-  color: #00979D;
-}
-
-.hljs-type,
-.hljs-string,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-quote,
-.hljs-template-tag,
-.hljs-deletion {
-  color: #005C5F;
-}
-
-.hljs-title,
-.hljs-section {
-  color: #880000;
-  font-weight: bold;
-}
-
-.hljs-comment {
-  color: rgba(149,165,166,.8);
-}
-
-.hljs-meta-keyword {
-  color: #728E00;
-}
-
-.hljs-meta {
-  color: #728E00;
-  color: #434f54;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-function {
-  color: #728E00;
-}
-
-.hljs-number {
-  color: #8A7B52;  
-}
diff --git a/doc/html-manual/highlight/styles/arta.css b/doc/html-manual/highlight/styles/arta.css
deleted file mode 100644
index 75ef3a9e59..0000000000
--- a/doc/html-manual/highlight/styles/arta.css
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
-Date: 17.V.2011
-Author: pumbur 
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #222;
-}
-
-.hljs,
-.hljs-subst {
-  color: #aaa;
-}
-
-.hljs-section {
-  color: #fff;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-meta {
-  color: #444;
-}
-
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-regexp {
-  color: #ffcc33;
-}
-
-.hljs-number,
-.hljs-addition {
-  color: #00cc66;
-}
-
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-link {
-  color: #32aaee;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #6644aa;
-}
-
-.hljs-title,
-.hljs-variable,
-.hljs-deletion,
-.hljs-template-tag {
-  color: #bb1166;
-}
-
-.hljs-section,
-.hljs-doctag,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/ascetic.css b/doc/html-manual/highlight/styles/ascetic.css
deleted file mode 100644
index 48397e889d..0000000000
--- a/doc/html-manual/highlight/styles/ascetic.css
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
-
-Original style from softwaremaniacs.org (c) Ivan Sagalaev 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: white;
-  color: black;
-}
-
-.hljs-string,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-section,
-.hljs-addition,
-.hljs-attribute,
-.hljs-link {
-  color: #888;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-meta,
-.hljs-deletion {
-  color: #ccc;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-section,
-.hljs-name,
-.hljs-type,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-cave-dark.css b/doc/html-manual/highlight/styles/atelier-cave-dark.css
deleted file mode 100644
index 65428f3b12..0000000000
--- a/doc/html-manual/highlight/styles/atelier-cave-dark.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/* Base16 Atelier Cave Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/cave) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Cave Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #7e7887;
-}
-
-/* Atelier-Cave Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-regexp,
-.hljs-link,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #be4678;
-}
-
-/* Atelier-Cave Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #aa573c;
-}
-
-/* Atelier-Cave Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #2a9292;
-}
-
-/* Atelier-Cave Blue */
-.hljs-title,
-.hljs-section {
-  color: #576ddb;
-}
-
-/* Atelier-Cave Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #955ae7;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #19171c;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #be4678;
-}
-
-.hljs-addition {
-  background-color: #2a9292;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #19171c;
-  color: #8b8792;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-cave-light.css b/doc/html-manual/highlight/styles/atelier-cave-light.css
deleted file mode 100644
index b419f9fd8f..0000000000
--- a/doc/html-manual/highlight/styles/atelier-cave-light.css
+++ /dev/null
@@ -1,85 +0,0 @@
-/* Base16 Atelier Cave Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/cave) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Cave Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #655f6d;
-}
-
-/* Atelier-Cave Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #be4678;
-}
-
-/* Atelier-Cave Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #aa573c;
-}
-
-/* Atelier-Cave Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #2a9292;
-}
-
-/* Atelier-Cave Blue */
-.hljs-title,
-.hljs-section {
-  color: #576ddb;
-}
-
-/* Atelier-Cave Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #955ae7;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #19171c;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #be4678;
-}
-
-.hljs-addition {
-  background-color: #2a9292;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #efecf4;
-  color: #585260;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-dune-dark.css b/doc/html-manual/highlight/styles/atelier-dune-dark.css
deleted file mode 100644
index 1684f5225a..0000000000
--- a/doc/html-manual/highlight/styles/atelier-dune-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Dune Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/dune) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Dune Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #999580;
-}
-
-/* Atelier-Dune Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #d73737;
-}
-
-/* Atelier-Dune Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #b65611;
-}
-
-/* Atelier-Dune Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #60ac39;
-}
-
-/* Atelier-Dune Blue */
-.hljs-title,
-.hljs-section {
-  color: #6684e1;
-}
-
-/* Atelier-Dune Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #b854d4;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #20201d;
-  color: #a6a28c;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-dune-light.css b/doc/html-manual/highlight/styles/atelier-dune-light.css
deleted file mode 100644
index 547719de82..0000000000
--- a/doc/html-manual/highlight/styles/atelier-dune-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Dune Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/dune) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Dune Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #7d7a68;
-}
-
-/* Atelier-Dune Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #d73737;
-}
-
-/* Atelier-Dune Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #b65611;
-}
-
-/* Atelier-Dune Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #60ac39;
-}
-
-/* Atelier-Dune Blue */
-.hljs-title,
-.hljs-section {
-  color: #6684e1;
-}
-
-/* Atelier-Dune Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #b854d4;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #fefbec;
-  color: #6e6b5e;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-estuary-dark.css b/doc/html-manual/highlight/styles/atelier-estuary-dark.css
deleted file mode 100644
index a5e507187e..0000000000
--- a/doc/html-manual/highlight/styles/atelier-estuary-dark.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Estuary Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/estuary) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Estuary Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #878573;
-}
-
-/* Atelier-Estuary Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ba6236;
-}
-
-/* Atelier-Estuary Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #ae7313;
-}
-
-/* Atelier-Estuary Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #7d9726;
-}
-
-/* Atelier-Estuary Blue */
-.hljs-title,
-.hljs-section {
-  color: #36a166;
-}
-
-/* Atelier-Estuary Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #5f9182;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #22221b;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #ba6236;
-}
-
-.hljs-addition {
-  background-color: #7d9726;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #22221b;
-  color: #929181;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-estuary-light.css b/doc/html-manual/highlight/styles/atelier-estuary-light.css
deleted file mode 100644
index 1daee5d985..0000000000
--- a/doc/html-manual/highlight/styles/atelier-estuary-light.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Estuary Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/estuary) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Estuary Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #6c6b5a;
-}
-
-/* Atelier-Estuary Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ba6236;
-}
-
-/* Atelier-Estuary Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #ae7313;
-}
-
-/* Atelier-Estuary Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #7d9726;
-}
-
-/* Atelier-Estuary Blue */
-.hljs-title,
-.hljs-section {
-  color: #36a166;
-}
-
-/* Atelier-Estuary Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #5f9182;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #22221b;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #ba6236;
-}
-
-.hljs-addition {
-  background-color: #7d9726;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f4f3ec;
-  color: #5f5e4e;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-forest-dark.css b/doc/html-manual/highlight/styles/atelier-forest-dark.css
deleted file mode 100644
index 0ef4fae317..0000000000
--- a/doc/html-manual/highlight/styles/atelier-forest-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Forest Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/forest) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Forest Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #9c9491;
-}
-
-/* Atelier-Forest Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #f22c40;
-}
-
-/* Atelier-Forest Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #df5320;
-}
-
-/* Atelier-Forest Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #7b9726;
-}
-
-/* Atelier-Forest Blue */
-.hljs-title,
-.hljs-section {
-  color: #407ee7;
-}
-
-/* Atelier-Forest Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6666ea;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #1b1918;
-  color: #a8a19f;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-forest-light.css b/doc/html-manual/highlight/styles/atelier-forest-light.css
deleted file mode 100644
index bbedde18a0..0000000000
--- a/doc/html-manual/highlight/styles/atelier-forest-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Forest Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/forest) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Forest Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #766e6b;
-}
-
-/* Atelier-Forest Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #f22c40;
-}
-
-/* Atelier-Forest Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #df5320;
-}
-
-/* Atelier-Forest Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #7b9726;
-}
-
-/* Atelier-Forest Blue */
-.hljs-title,
-.hljs-section {
-  color: #407ee7;
-}
-
-/* Atelier-Forest Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6666ea;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f1efee;
-  color: #68615e;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-heath-dark.css b/doc/html-manual/highlight/styles/atelier-heath-dark.css
deleted file mode 100644
index fe01ff721b..0000000000
--- a/doc/html-manual/highlight/styles/atelier-heath-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Heath Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/heath) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Heath Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #9e8f9e;
-}
-
-/* Atelier-Heath Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ca402b;
-}
-
-/* Atelier-Heath Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #a65926;
-}
-
-/* Atelier-Heath Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #918b3b;
-}
-
-/* Atelier-Heath Blue */
-.hljs-title,
-.hljs-section {
-  color: #516aec;
-}
-
-/* Atelier-Heath Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #7b59c0;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #1b181b;
-  color: #ab9bab;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-heath-light.css b/doc/html-manual/highlight/styles/atelier-heath-light.css
deleted file mode 100644
index ee43786d12..0000000000
--- a/doc/html-manual/highlight/styles/atelier-heath-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Heath Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/heath) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Heath Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #776977;
-}
-
-/* Atelier-Heath Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ca402b;
-}
-
-/* Atelier-Heath Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #a65926;
-}
-
-/* Atelier-Heath Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #918b3b;
-}
-
-/* Atelier-Heath Blue */
-.hljs-title,
-.hljs-section {
-  color: #516aec;
-}
-
-/* Atelier-Heath Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #7b59c0;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f7f3f7;
-  color: #695d69;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-lakeside-dark.css b/doc/html-manual/highlight/styles/atelier-lakeside-dark.css
deleted file mode 100644
index a937d3bf5f..0000000000
--- a/doc/html-manual/highlight/styles/atelier-lakeside-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Lakeside Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/lakeside) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Lakeside Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #7195a8;
-}
-
-/* Atelier-Lakeside Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #d22d72;
-}
-
-/* Atelier-Lakeside Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #935c25;
-}
-
-/* Atelier-Lakeside Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #568c3b;
-}
-
-/* Atelier-Lakeside Blue */
-.hljs-title,
-.hljs-section {
-  color: #257fad;
-}
-
-/* Atelier-Lakeside Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6b6bb8;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #161b1d;
-  color: #7ea2b4;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-lakeside-light.css b/doc/html-manual/highlight/styles/atelier-lakeside-light.css
deleted file mode 100644
index 6c7e8f9ef2..0000000000
--- a/doc/html-manual/highlight/styles/atelier-lakeside-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Lakeside Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/lakeside) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Lakeside Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #5a7b8c;
-}
-
-/* Atelier-Lakeside Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #d22d72;
-}
-
-/* Atelier-Lakeside Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #935c25;
-}
-
-/* Atelier-Lakeside Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #568c3b;
-}
-
-/* Atelier-Lakeside Blue */
-.hljs-title,
-.hljs-section {
-  color: #257fad;
-}
-
-/* Atelier-Lakeside Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6b6bb8;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #ebf8ff;
-  color: #516d7b;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-plateau-dark.css b/doc/html-manual/highlight/styles/atelier-plateau-dark.css
deleted file mode 100644
index 3bb052693c..0000000000
--- a/doc/html-manual/highlight/styles/atelier-plateau-dark.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Plateau Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/plateau) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Plateau Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #7e7777;
-}
-
-/* Atelier-Plateau Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ca4949;
-}
-
-/* Atelier-Plateau Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #b45a3c;
-}
-
-/* Atelier-Plateau Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #4b8b8b;
-}
-
-/* Atelier-Plateau Blue */
-.hljs-title,
-.hljs-section {
-  color: #7272ca;
-}
-
-/* Atelier-Plateau Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #8464c4;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #1b1818;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #ca4949;
-}
-
-.hljs-addition {
-  background-color: #4b8b8b;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #1b1818;
-  color: #8a8585;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-plateau-light.css b/doc/html-manual/highlight/styles/atelier-plateau-light.css
deleted file mode 100644
index 5f0222bec1..0000000000
--- a/doc/html-manual/highlight/styles/atelier-plateau-light.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Plateau Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/plateau) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Plateau Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #655d5d;
-}
-
-/* Atelier-Plateau Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #ca4949;
-}
-
-/* Atelier-Plateau Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #b45a3c;
-}
-
-/* Atelier-Plateau Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #4b8b8b;
-}
-
-/* Atelier-Plateau Blue */
-.hljs-title,
-.hljs-section {
-  color: #7272ca;
-}
-
-/* Atelier-Plateau Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #8464c4;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #1b1818;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #ca4949;
-}
-
-.hljs-addition {
-  background-color: #4b8b8b;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f4ecec;
-  color: #585050;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-savanna-dark.css b/doc/html-manual/highlight/styles/atelier-savanna-dark.css
deleted file mode 100644
index 38f831431c..0000000000
--- a/doc/html-manual/highlight/styles/atelier-savanna-dark.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Savanna Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/savanna) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Savanna Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #78877d;
-}
-
-/* Atelier-Savanna Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #b16139;
-}
-
-/* Atelier-Savanna Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #9f713c;
-}
-
-/* Atelier-Savanna Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #489963;
-}
-
-/* Atelier-Savanna Blue */
-.hljs-title,
-.hljs-section {
-  color: #478c90;
-}
-
-/* Atelier-Savanna Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #55859b;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #171c19;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #b16139;
-}
-
-.hljs-addition {
-  background-color: #489963;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #171c19;
-  color: #87928a;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-savanna-light.css b/doc/html-manual/highlight/styles/atelier-savanna-light.css
deleted file mode 100644
index 1ccd7c6858..0000000000
--- a/doc/html-manual/highlight/styles/atelier-savanna-light.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/* Base16 Atelier Savanna Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/savanna) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Savanna Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #5f6d64;
-}
-
-/* Atelier-Savanna Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #b16139;
-}
-
-/* Atelier-Savanna Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #9f713c;
-}
-
-/* Atelier-Savanna Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #489963;
-}
-
-/* Atelier-Savanna Blue */
-.hljs-title,
-.hljs-section {
-  color: #478c90;
-}
-
-/* Atelier-Savanna Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #55859b;
-}
-
-.hljs-deletion,
-.hljs-addition {
-  color: #171c19;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #b16139;
-}
-
-.hljs-addition {
-  background-color: #489963;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #ecf4ee;
-  color: #526057;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-seaside-dark.css b/doc/html-manual/highlight/styles/atelier-seaside-dark.css
deleted file mode 100644
index df29949c69..0000000000
--- a/doc/html-manual/highlight/styles/atelier-seaside-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Seaside Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/seaside) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Seaside Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #809980;
-}
-
-/* Atelier-Seaside Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #e6193c;
-}
-
-/* Atelier-Seaside Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #87711d;
-}
-
-/* Atelier-Seaside Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #29a329;
-}
-
-/* Atelier-Seaside Blue */
-.hljs-title,
-.hljs-section {
-  color: #3d62f5;
-}
-
-/* Atelier-Seaside Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #ad2bee;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #131513;
-  color: #8ca68c;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-seaside-light.css b/doc/html-manual/highlight/styles/atelier-seaside-light.css
deleted file mode 100644
index 9d960f29f3..0000000000
--- a/doc/html-manual/highlight/styles/atelier-seaside-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Seaside Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/seaside) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Seaside Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #687d68;
-}
-
-/* Atelier-Seaside Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #e6193c;
-}
-
-/* Atelier-Seaside Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #87711d;
-}
-
-/* Atelier-Seaside Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #29a329;
-}
-
-/* Atelier-Seaside Blue */
-.hljs-title,
-.hljs-section {
-  color: #3d62f5;
-}
-
-/* Atelier-Seaside Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #ad2bee;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f4fbf4;
-  color: #5e6e5e;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-sulphurpool-dark.css b/doc/html-manual/highlight/styles/atelier-sulphurpool-dark.css
deleted file mode 100644
index c2ab7938d8..0000000000
--- a/doc/html-manual/highlight/styles/atelier-sulphurpool-dark.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Sulphurpool Dark - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/sulphurpool) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Sulphurpool Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #898ea4;
-}
-
-/* Atelier-Sulphurpool Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #c94922;
-}
-
-/* Atelier-Sulphurpool Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #c76b29;
-}
-
-/* Atelier-Sulphurpool Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #ac9739;
-}
-
-/* Atelier-Sulphurpool Blue */
-.hljs-title,
-.hljs-section {
-  color: #3d8fd1;
-}
-
-/* Atelier-Sulphurpool Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6679cc;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #202746;
-  color: #979db4;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/atelier-sulphurpool-light.css b/doc/html-manual/highlight/styles/atelier-sulphurpool-light.css
deleted file mode 100644
index 96c47d0860..0000000000
--- a/doc/html-manual/highlight/styles/atelier-sulphurpool-light.css
+++ /dev/null
@@ -1,69 +0,0 @@
-/* Base16 Atelier Sulphurpool Light - Theme */
-/* by Bram de Haan (http://atelierbram.github.io/syntax-highlighting/atelier-schemes/sulphurpool) */
-/* Original Base16 color scheme by Chris Kempson (https://github.com/chriskempson/base16) */
-
-/* Atelier-Sulphurpool Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #6b7394;
-}
-
-/* Atelier-Sulphurpool Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-regexp,
-.hljs-link,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #c94922;
-}
-
-/* Atelier-Sulphurpool Orange */
-.hljs-number,
-.hljs-meta,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #c76b29;
-}
-
-/* Atelier-Sulphurpool Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet {
-  color: #ac9739;
-}
-
-/* Atelier-Sulphurpool Blue */
-.hljs-title,
-.hljs-section {
-  color: #3d8fd1;
-}
-
-/* Atelier-Sulphurpool Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #6679cc;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #f5f7ff;
-  color: #5e6687;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/brown-paper.css b/doc/html-manual/highlight/styles/brown-paper.css
deleted file mode 100644
index f0197b924c..0000000000
--- a/doc/html-manual/highlight/styles/brown-paper.css
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
-
-Brown Paper style from goldblog.com.ua (c) Zaripov Yura 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background:#b7a68e url(./brown-papersq.png);
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal {
-  color:#005599;
-  font-weight:bold;
-}
-
-.hljs,
-.hljs-subst {
-  color: #363c69;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-attribute,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-built_in,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-link,
-.hljs-name {
-  color: #2c009f;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-meta,
-.hljs-deletion {
-  color: #802022;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/brown-papersq.png b/doc/html-manual/highlight/styles/brown-papersq.png
deleted file mode 100644
index 3813903dbf9fa7b1fb5bd11d9534c06667d9056f..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 18198
zcmZsCRajhYlWil7yGw9LaCaw2kl^kP!M%at?m>cka0u>ctf6s&e8CzTLSrGMaSIUS
zWM7q;>fa~s$OpT>
zFLY-GO$7j;Wl{{7eE9cF?XPU&ukYpLA870A2vBhFvU6lq^RRVx)N{0T2=eQ4J41(5=2G+8;)w1ZEPMkbF2bGnazV|OLZz2Hb@=WyXBX0)f+0o;fWze0N{t<*y
ztIiNnZC{LRA&k!$ZY8RSSkRr34SfzyO1FQ1#+`5DKBGKIaW*#IpS|)H)0b)RO)vVT
zdmZs``V5~Rd=7^niGNRi-KohFdl7;cLNt=6H%jET$<@@a?HPC}DI+UeV-R$j(|Cgb
zovyEp&h`&JS~h*u+dsTgScW2zDVr4f~DH;Zx@cQhlKiyzUik!{j?26_bcGl3n
zz;xi(8ENgs!;6LMT9?9^)|SgIm+Xu<9pAn@Jwvr@j|kU$Ps<;yJK|Ptilz{)cF~50
z>3}X}-GE2L$gd5vToUcA;ufTe+vCmq6y;EHLIF1Y)!*mMIk7Ufz`-6@{%j+0t}5by-kjAimHgt*AfoWQ3<}2%HH1G)X=gxwsGTnqo!jS
zPp^mHU)Wdo9i$J93f_cGL~o081HVh2MIfFb&r#24&zMhy4-B`@-M4wqKeV5e3rOCk
zzfxnXb=ed%7QxZsGFZ!Bk=ojIqXM0lz`=t&N`(ieb`uT$vaWG--x!ps=kokELG7^v
z+{LRR;H>H{+#Sy9)~}T-X{s*WDIF9ko?!YOUrBL6c1UTt%|c-C%-R`h{*D&-?xTv6%U;Fy)q@zD7n;Mm&VTYo!f>`4|^@IrUrWqi<2`
zIK=%8Y>k7_cJFc62Fm1dsu5V%^D!kOF(oA;3duw
z%pO09{DvbtIv+U1{6MQ8Wq|e~4(8RFaZSiu$
z|CJ~BTvRLdM64V`xYr`XpzSoka%-H{0)Ro-jT6+}
zT18|CY&T<`K}73~WMQMkzj<-{e`EjOV2Ch(n321C+#16;>MjIhblly|M?Br0UERMA
z8yIvk9sVuv0~h)1=S{wY{&V6fDi@0c8|@S!>h`gR_^u~(f!y=uu=3o8U2>$VV-mwV
zeJKl8K*mz%0O$3!XmmqEd#rW!>oY?U<|?CBsX=UMCSrinA}B9GA5MTUzn%ILQD=}Q
z^-qc}to5D!{UYEBFfSF{7{}5#I2`7!9Xcs|{e!rTVYvNetFc@43N$#e!DM_Y#5_4V
z3P*)qJyw97IJGZYj53iEQKK~Zk6QE|wnDAQ6e%ci7WM9yX{3Voy>2v7-{dW*|+Zvy7%^(o^DMc&%_Tp}4@Jo%0Bs7ObY$K2QS=1v19slY*WwV!8B05I;*7gc|
zC}iWT!ocL=zoXCa-*EVkQZPGoFVou4>|(ng{&T`5ns(d;`0IWRE4$3aCE
zX={pif)xfKL2J&CwL-rbsVhFX~Ast|24AzGCb$6bP
zzjP96&p17?0`zA}Cr(1{-
zBWmAc^Tih%c@PSpJD39Rtvbpc27|&`W}18q&trP3z4xp%4^t5T!T})zWON*!hQ+0C
zGnKXI-(t5+$xcN_*!vy^Ebcn(`}3GQ=EjrR)jEu#)a!Qo+uU^L6Sf!vtQo@-)YCH_
zIkq!}#RQ?#H9Na)c>fA?i%F=AwN>+%6IHG_6~07@;tNMw)pj-py?fm5OAkUXC)Brp
z)eG?cTAV-ODy=aRrlcS^!0S!95GOO@_zy6Yr~oZODHiWB(rYDHVW+oP+iSHanvW_2
zD+33#kuvw;P&BQf8OM-`63t1%h)cdnm8}>fIrS=425~>gpk!*nOPF^FRJ!}0{NO(e
z1ANE&sU_mPMS;Pw9^8F*v5!k1Dr?=^%?eWij0f~to7y`V{K(<#9fgxsh1qZ}irc;t
zApc;fE}TBG^?-(ZYfC3hk)rzA9||a50&`5$fOMODInB^CQQz-%|FVW(Me6cd&RQ!Em*`8(cOiTV*}I0^
zkh9#bz+b`^Achh+t!T{E%m*7Spr8X*#NFvrNeQKR9N#NYImXo$orFW}S#|kp!g)
zC|mslRtj
z{<(wk5heSmNTLQPjVu+tu`Ax0<Jp<3;sv=x5%C^te-lbQRUIA>ktvMAj}|$FYU$Qp}=T~;pv%9btR=dxklUy
zkR9E*9e)3CPHhghYGI4o&yB<6Ek^@&s6_$^hHm%y;$mG#6s2Gj@yUh|7NNvbZ*-CiW>(`$PB*?kxl)}lSZKB^Wx?u%oy%PiU;Ucb|V
z|JbtHI`e>wDu43V9mbmTz-O*hsj=x3p@_52uHWdv$KHWXIJ?hAN_O+SE^)}7#rG|6
z_BKM`Ghwpm2fNaI-XM&&0MIfLw+nk~2$Q9!(m1H({sIm*PjV$tD(vHzF8J^I
z$5d)V3#P=#{X0~lkvdz*hO?2|P39$67m%BB>cJ;P&i?e>f6oD0A_x(fXnlhN8_iy~
z=8_i6_?scR{Q@F{<_+s`6F0?)4q>Y!TZURG@z1Xg(XF|Uq<7M}+x3!5CKzKPU%EBw
zWsc%dMB{e=rbNFynyQz;$Wk>xdNDkRB!r}hPlheoBDRi4NdE0U68C8T=FwmB)E|du
zu(3Ry^ER}qt8o=s^t;)ka7?Rw9BkK-AbMm!5YyN{n8j%4(FS=#^NXNFzOKvDh-fh_
ztrMuN#+;}%O*fdC_O-zikI?cL4FkQFbMJ&%;LsLdp2pU1z81byeDrcnfVfSPjd&Tx
z0uTNCRa&zYgwCK{AP>=r8Sx{G=0I#zQ4SAF*CLY5@Ge_3>$_ebR&z8QuoP^G_nMbA
zR!J5=NfW+bA;6g4yh|56J$}zRiUEt*T!NqU4MM$Ik(YO5ElC
z3I>TTR5(&RS-e$~mJ610i3Tb|O!%oihx2Dou=SDi
zY8QGbi&iMst0x9N)(Qw|m<=v9=H$h=d9q7_RC$8&xiTCpO(nAT)09jNd*kDz)xA=d
zA>mDJMEO}wm=z8%##p8Epux^Z?6*hT+bBf^Yw~9wh1mOBI2*B_&;n6YqN$_sLi+`r
zN+}oUEH%!)UEZO0kGwoV{fV0125Liy{XQRjOG;ll15xL$5w(ynu*BE#Y!uUbJlqhC
z*)p9Akd=!p3VXT;Mo_Zvej_{xJkq)x&0<&B)@Utjud|co5aPb~dM)3OKXKmRzZ}RD
zt~hR#D>70m`e$6d9RY-q2@W6QANld%IvZ*VmwpbdVCzWDJ`&UO%hC*(c9AJ;
z8qe|b;=knC|ZRghL9-j+JpIpBjS
zLIz{G#rkZ%K&UOs1pgA;bi1JjfXryT;9AV*AdF1(P;A$V^MMS0X10gTzoNjJBTB;U
z#kJ5|QkG?|zHY}$^ddtj_$wAkIcd;Wk|&B6^`fnOL3uIPj@Z+b!gftAC_YE@sh~EY
z@awBver>U-j(pBMf%*W;OI?#3J3yRO&^PqFHW`#yr|%#0rDM+^ZV
zw!IXpiDk0Qo5iL_mNZlA`+m>mgyn-Z9(
z1VK4OJry2Iq?o90-NhDNVAP3Niev{MJh~PQ7M5U9?Ob1#H}q=Dgn%~Ng=3b;7jX>n
zADv=?=pgaOIN2G2JCr_(7k0YF#OlE0c}by4_|pb-iJ-CYzLbWwHs2A)ZY;uuYwbQMUa1ed5)1G+DXr$;MC*sQ-N@4$xD327+bTrT^
z?kmr?X}=Lu2xf7X5|gkw#k>FEC139#QtL*Y>C)kvvqB=d;fVQ8{+;RhP-)is9rX&jj-Ik
zT00%|O4wv`6`(M(&W*hs2A
z?qIa9QPvO>*ssTM+$((GcA1>?(C1jm10t6@Dy(k%HtIN+5d!Bk;~J%32ZhcKu$-i2gOM1Ek)Av0js<&PBErK4
zp0BqauJ^Yy7bnHdyGOO!FbWP*qG)O@I>y%wAIOX9eD)7R>ow6xlYRy-h|ZmQaLshv
zm7r7H)>I5~>_i>NDSv6k)mCwZu$9K6)JGn#ni#>O5}3aMrYt7e67}_&zNlt_@b&$n
z)VO|sK6qnt57(FA0!{d&$}h!DdNgOgYMn=8${CJ>S2YIAe
zYh9atd77_K6soYC+WALnJL7SxqnE#(+1G`m^0I56gta@e+L0z>IRG+?>DS@Oe-NlQ
z-mQ)F{=7b($L)X@jB5Ot*D*>ceMR8793ItK-tTO`iAnNm-xzYn0#;&=gXJYz8KmnUBrL#cb@ELwnkp?O
zZZ{8tSRklRk}8Ts29G>v-&z?qob#qYSe!ek
zt^r`X2W(J?(qxhOf%h#^?8D`^&MPbuUE9s
z$80u<1iU&&+mQB<4bZeyBaOB}$!d@`^f4+iXS3;h>rXP~*FRrr)Wki^(q)&EwAMt?71xOWwtXa8UsY(_;C*7d*d9Z
z-#(@Mu>`+6lrEC|=E^q^u&A=e+P9|#`hdP0Rg9`gUbNqm@!-Gg-V6vL;!*U<4ZtIa
zv@cWy_^m4cV=F@sv3lCwx|?r%lb?NGQobaW&#Mi<9dngpq({-uy?xwAR&#MBUtybddE
z1Ka>|_TRpK@#mBE#M;ka;RDR*2pXmP#YHG|5qh#YgXDUPD*cs3)>>Co@wnbArjo;_^QGnuQGdUSqu6AMPxBHbW99c9gHFZ*u&-M5cS}n@d
z@wWUbV?X7y#NTCaqV_t*)w+Vzpte?L^08$=xiju5lCZ4~#~@34qa{rJM!{y~Tqe5H
z-`N}U;ZKj9jnYas%EXCD=*$|XC$h{m@?;&T(uT--QOR_H^PcjyAP~pc&dS&v#J%KN
zK|)APC-pnC;EKdibKx8O+Pqef?
zY3J^)uf~;VDge4m$gh`Aj{?OYnES!Tftm1kjZwLB-5soBf8q9RaPk~e{SqHq+Gh(R
z<}KbtcWaoIC!do+k`h}5s~QzJ&#Ro?TzU_eO^xAgvNoX&oKS7|-8Lm;%2@BRKwb9H4rRICqXPIQLdOMGtG>0(Kh}5xDzW
z<`R5ub7|^ov6hX(i^R_d6ZdLQ5t}vu@?2|ueBl^W!CoR=LZ1Urel(cC{`jK##xJ5Z
zW6m&PFV^e{7~mrz4!xy@n!O%C(vIRG0g>FrE1t+=n3;z9D!vWHCUjqMi*QAc4!hId
zk9MAo2%jf}g*lzYPM7_RYQxo3rJR%jUCd5FoBmmSn@QTM@?QERM*E-uEb}GD!7+W4
z;ucS;Fa1*ZgF9U&8>R&|tjy3FH;93-Kpof^^nCm9kp4U+SFqwi@6}>$jo4)7x?L*p
z5eHsG=We;aDoq*x+H6v7x39;dP<1mgK0fQuG+#L+=2<$z#m5Z5
zCEto{j1wIIxQ(7>!yi2iRgQS~c_6N5JHqo=$`q=PD?Y@90#727stD}1n!C~qy
z1q^LAqT}jq4r2TFIf&-|vYu|DXI}0>^}2ev5jUXZCM+ZOWL>l4t}d2Pur%y+XM$j(Cc126Ww7ST~4S;g=2q8j3!|OoWynEtKkuUjZ>k
za%azP+sS^P^KJ=|`TAdnlNkRHqn@0nFWdFeMoI4-_sH22UA`hq_xA?B;_u;ixDrx%9ajWMqLgzfYCofw8KF`gO
zWh92d@!_T((;rc7)Y0;~o3^0R^ALS8opgP}hX%hpsuO^eo@L^`#d1RJD{m2kN6wGw
z5T;|y=;jNZl}W2j;Bc$yGn_%Ti(Jtk4%`
zDK5cCl`%fdh(p%F!
zN4;@Huf@ukLx1k|0(qt;@&Xiw=4#8cVPcfFDX~atn}9jl7(Tz#p-Q|4F%ywo(jlv#
z%qISsaHlw>1|(CS*2KqRSCP8NF(6NfJ>HP|lV`v4llSyqeD!0%X_1>
zg{vvN5D0m~n!O3#;}}s;n>z%iE0e^EX_%IQaWRp4yx4LOzqV3T+W(;k{udVh!#EJ}
zgnXu%H1P~HO=bwcbt57%T)u4QT05g9BA!O6PoHP#DPg-80&W|M33F=n@!{4j6>-=9
zl9KJP6S3H+U>;T?}#WA
z_O%upq*IdOTe9b~q#{Y}07vk515LC)Il|+Aa$f}Tcr-&vQOIH)UZ$6&
z36g&<+>7?MFwXUe`uwpa`gVyIwLJn~p1QK-H&X5vGa};Wdy^Q_m|$Lgl*a(g9EO{h
z##w%7(g(SjboyvXP~vP72(|N1)ZI{XNa-&bPjF54D`q-}^mUm=DGk7I_a#t~zNU)>
zJD=vyGTVi2y}*&qMByXD3Tn-Wj|5S#f(
z1uWJ`3RnO6rh+Yy?c=B~PUJ?nV_{w6l7FulT#(2M_~r)HsCX+L?$5L39mEvBSU`8$
zYq&EhHXoxg(J-om_c-fe@=~3q#OG#^kYLhMnV)y;ZF6Gqz_mr2P
zugbL0xc8{kyxRcLC?m)K&Yj$%)>_B@og|1@e~QPf=dh!p2dBQAtX$a~q4}AI9ArA;
za(4@-P0mv5dlML~u;DO#U*_mx8yZv31rn3O5F4pLW;#xXKA<~u3@cMIw&h)_VR
G3S-EN>9CM!{YB*|;6wg-K3V?)eR((z#1
zHyX+Us~H@9)~!8`K-#ZDU>v8HpiaQ|@=VU5MgT@ehzQ(1nZ!M0ZDk{Fb`>pCb0vQE
z`gX@ZK}6S!(-($v3w8-+L6Xs~;@WTrR}q42gH9p2ncZYDab8*`#p8jbS&H9$DTx{1
z|8L)r+}X3oIp6b9dN^fZsl0TpRK4NW^TVGZOit8~r*qM+QL3pd7G0|~C`PHxw2PM3
z->n8iEh)LU)Je%r7nEt|D%&F&(={XI*19z_HKI38aE6Cfm-buU7W|=mo3gMA57~g`
z7aBx4OS&(O5w@W;2pO@ZVyG;2^F+2cYshx%M2*M@%;(4quYc}>z1WX(9ccb&>8#{j
zE=VlFg+&2-xsr%AY_}ciz4+<$^}2TO2e)byPmJl?+aOU7{UVx$=ZNQDTQLxsh}+(_
zak-NBw`v4=+Ydp_L=w^J1&NT$-AbEUuj%8LN7nJzt^APyl$(ght>;(o{)xCqf8IX6
zq`a-CyPq$UOPJN(oo>$gX?v65Y$GnIq7Fq?=??};kY4#Na69k#iG|Wd|{Tt
z&uFLgaDQ4)`{9^3rX|Bg
zNY8N2w1??HVsq#}Xk&RcmoQBacog;CZ%I-HU?7dT+nZRo?h7BQd5Yrv%sI0rPF^Sk^9@l-_4``bwK!A
z5Ud{#8B%fMPHat04G9kj%j5>0maQK}jQTzGC!2<9FicZ-#V^ZaC)A?QK9EelA!nP)
z+Z2DqYAqTsfZ9k1CW9+h;Uao59}OnJ9>r}xs&nHlM5^Y58T*TkM80zn8=UE2e8u{j
zpH(Cv<_IWBdh<6_f1={d7#R|wGLcIoegMU>82VZLrcn;{FuCmF59Tpu7qQ5TEj5`AFXQxx{XS6|0N#
z3g?J^0RDM8_l@3M4G0f^O03>$S#_it3cdG%7HWo_Xb-<{a&XHHzW`(2t54<~-m{AO)J~7AhPI
zbkz9A9Eq!7aijhY%^=rG`j6?w^hb13^_LKf!X*}jaV$GaXvsies~+H0T#v%OcveHN
zw6t*A@XdVfqJIPsPwPO4;>%M4C+{dTVU{cOk`3puW6b36K2&z%>btSk&&H>Z;<`p>
z`FMTMiHw&wOXcQ$-Y{pG@3aN}s_>;#
zeQ6GDsqIMA?iz{B1XzIIegeu-#qL_ZBH|eh`L{~J(A{bH*vND8W}io(WZ9s;;m3qZ
zElXp!ru)Ht+yJJ|dfvRtcX?~Pn_nW{zZbM5z3mB?Hbf_|+7ZC-9yVjR&7mnNul4vE
z%KEK*b1~tReV{kNh2E=&iwgU8w0kYs3c1o6m;*fZfrF-g?1!~+<-`f!Dj8+i7NJUI
zcZj}vt?|8iHQ3TdM;gn(X(Vidn!cd{^x{>dX&Vt^`^_3pu?t)#>x|K0cW=egSMl9#+mqq-8|RdMP1Dw
zx^5}L#|i6)ERW8LBjm}wD6@3$`!cXl0aV*W>(xz)J2m+v|RNGEXIA%XWv
z$Hx$v!@W5LfaU7iEY}no2e;*F&dh{F;<$?``JyH&l3RVjA{xC=Rq{
z6}dLQKK(BW4N!Y)Mzd3h)PX8L3OR6JX82vsk%|<`y{3G<99ycR8(ZD;4@=k|d
zx1nPOrARPmMi86c#Qn^1g5RVk00)%LY3fdvDm`_|D|ZP>a4hmnJmTiqc40*eItZ0G
z(Cfxe`6oWB{4L&V2-lf)Dz{MkXQ(A{E}?e1cWU;s-J?xBbGBUgebeTI{+k+LT|P=A
z;GHDn*981}=hBJAGXPX?iXEu)RoZN2kKn)}Yp)=+)%`(=Hk2z^Csu^a+hNSE9<}O4
zW9BhF843QW<{+N^4NZ(+Ohu0L$qp9AhpJ?UbX8~fibx(>f3CRh|ZH~FPW;%L4
z2Jfb`#^2zr=0rNvM5{6`q6x-M;QJ8B$W1lwJwBT6OTa+L|E?*68NnD-d
zqirI@#!DTk6=nvBq1t|F2a57+*JomCoPO&bkNHd&fq@7CoA#=ogI@ER;^g6MTjnNJpU8$17lkcby!fn#Y^cf59qs4;WjW9@I`pu+^=!$XvlzSp
zHl-BP6qCLifc*pwQ8vDfUY0lgjC>>zTLL$6VLQBKH2U4M(&?%A718nspPj%tmUBw+
z#X>LH_#p;`9!I5vv6@cVh1b)~bHTXz;!@s>4omWjec#A;((g=Fq_p{u1|<#I-D{h1
zr%{sZ%zv+3T?)s{c78c|r6Ez1kf5OuRJ<^!_`!;|HxG;mZiSf=CdVqy^)Fpf=
zR6<3YrraF!c1|tIJ#;9sg<)`+=a+cw8*6)$-yV3w_=*W`MB#~zjz6^LYX4eVoTxdI
zc3h_Bc-v+z^z5>e3vEp)brfA?bQ>r1^-8x`-ATBNL)99$&
z;rXG-!IBn08OxyuZoj`hcQ)a@7O5;d=o7$6_hSTJ
z;(^Dr%6p+QhE473G62?L^T{&S2^UB8^~fFHE0@wP^b_T#h%rn7^=(?yQf+N!)<~#c
zB&mh#W%khdZrGJgs@ixb%h?ad2HG&$G8+QXR6zbUk;$(r4F#>F^1>Br!mAfDkRR@D
z!K|#|oQjAh)DlY~3|CG`+4@opGIM
z^i^Z4rXu>d*NVXngpKKI2U_*K}S3_}=T|7q^w`XB`
z2D5mfvT(`vMwh8DGJql?=LI15;DsNI&n^nhYwgI&-{a#V-{;<=cJWiZ5HEkDY(4jD
zc2?xCALMIz@)_iwDG(vRJQ8kP7xC8|N5n
z-mb8AOpEdA->ZPnh_c<&o3Jg+X;AwynF(`1Ihpp9xt|hy
zu7!?dLSahdVg=JpZk#xq{L7i0Y3(N`w+}g
zn}vYJKK$VH`HhCBK)g%Cw8flu&$)8+Ef5m{+5}|bRYsP&t~Jk0TLEENO=yT3nrvyfYKk*n#uYjkyI9wC{A(mO8ae&B%;9#dTh)|_V0}&D>^xO(UZ2e
z2{_|CZ)7#U(3yWf5i9##7`c79OX{6Y8(moRVE~tW6|XopYg$JLlxm|Q3X{o#=h{Lt
zyCavxXR*2;2qGJ^XJ;nKfb^TpVwPUUM{br*(tWeRu{4Id4v!3gY2#K~T^)u_Zer}E
zn_7xjY>yK@ouN|9;O0P^ZRT#CcRfGYf%F#Vs;VRb^a|0p^Z(QZ;v
z_h#9VcRfJ+!d^?N=4N?P&mP&Il_OwCQMpD;0zHfk@ay$}8TVzgO~mUpV_LitM@Q8z
z?9S+w#)-R7Wlo;vsZz9D@#pj>8Cxn}a*?q4(u0!Y^j5C?U$fc+Q?CL`w3ANg?&_1
z?FycB-DhP^mg2^y?@lqA_P>^f{|QRaU~igN=blSkS9CZwMjy&9MHhfv%{2!{eynf`
z$pvnj!j!PJ^$UUrQOmKo@@YFMK}y`iI9Na(F-H2m)K^;G@|^OUI0RWuw$|>Zi>>4v
zq8|c(foEJT-K`qR-DS&5P&JlKeXe6o?f)$qE9Lfsl2!ik}0GeaVk8W1YV42f9!
zrDpRi_q@-CcyuXkqt%*k_=Sc09&?96Tu==56A9)J#}xMwb)PC2fO#x-Caabw>Rn0y
z{HI2_IqLYwp=X|p=?Np~=954+Ml?kfMhR7O0xujiI*!b{uTA~|{_q>bBp
z=-{T8<|tDq3CTI;lW2D@h@1>&cH*BDa_y{)8j?pQ@ST4-bycb_leaSjIqXOg!I-dI
zwNUCuLgX|9CoCb|R&9g{#A6D$#nUq#?A;pr8AdUx?+Mg??0rWBc7w@CmP8$GxdE}e
zzHzq~`$CYEEw*mQui5d*E?e~uhB&}WX3EcR8?CKn>HfFzpYY*7uYx^#J!@o8sI_T#
z<9>7j4!UEiu=RQ98@44ed!uGToSby}kzEY$x!v2ihKXiyj2);!CRiFr>vI6V7wV&~
zpF$-W<*Q*jZKoda1CDyKwXd4AY%8NW?9?a@Yy}T{I
z8l%pzl#*N&hVTtVAK9|*u$h3nx1=6hC?%PgdUH$1
zgU4B#9LvX`-GA_Cqken?Okqp8ZYE~ymacnbL{jExU#!eyp{f&~&7KrUZ(@I$|
z*^;qz>W?cO%fU+}`r^A}yw+(=Jny@=CHlQvYr*sZn~Mq?a}U+deU_vMDx=p%_S
zeq4>UTvg|Ns%zPo!tKDK1jo!MHXs5k!B@$&Iw30U0NMQkIcpzN?DYb2*ymZtS+0tL
z|7ZN81f&h|3Gcxa1-K}FIu}UC&Q5;*yA>^uZA?ny{4)}sFcUL|IrhZMoeaaeLpX1W
z;w-j*w2UV02#G(CdabMIPx^&kQ$y&xwe3xF%dn^Zx=-2>R>1)!wONiAju(G&X}wa&e3M9e@y*jUOnq=Da;aeY3U?)V#0wlC4b>zD
zYg41RpwFSrtQS5)@i*U(!g@ZK3qpF#ekkwhzv36}MIRhhvDIX_{kvF-w-i!URUy&1
zZ(GVLd13Rxa`n}=54^&rT5t6b{-~*ny>~1i9TpVYZ!wNEQFHytZc3QlVJihZ*&r<0
z+pVZ@C%9pIE7QsXE_Wp;lEw)G|JA?Qr?Kw4JQlq%?zBMH%3
zQ6JVx`e*&{{{B6UR&7EDCoSR>Ia4d+4zz1c4JkkrJzYuTQJ&qreUvcDtG1l9xOB(^
zrc~7sn*MO0arcJ>5^dNJY0Dd`dhvNp0zvzsHa0TO=<$99GqoAfRNXiNXf(!*IEnmP
zr8tbeCb^b*$m_VvC6g&*bjtGqCpo-Ox`{)A5lw;yGH&b+sGu3`p#9`TQsPue)fUR<
z&`V+$NVA8gzWIS^yrU#20h!!^9m?LW?#vpgS2M(T!&ts|UtGu)ibm12hjYQH3>Qh9
z&4Gq1i{aI05C~XPmovUh_g2b!EvwQ{JyK_xNk>x&ulaux-hYGOKQD&wmOXCwH|wi#
z>ZA;Hh-sqvZJyfmPTTsim;OTNb>l5w$r>9)Wr+8Y$ptx_kA@kv@KugIc@7s51}<>$GYQ56)Ki`;R>$*#5fm%=a3oHXA{2r
ze(gE^q7@6M#NOKDk?lQ!5v+|OS})<3Q$-XinH=iC%oZ$K*8mR&EYajonfKIB3qJw`
zEh)zGw95_xD1yBg7v#8+sMaF^CW02x=1c30XZN3`1|S3xsHPU&%AtideyTVxW^pmN
zC+CEKwcWLdiPK%WA><$Zk_5~1-n5;YlQ3aqhz90Q0Xyfxt(2@|0?VzodBvU=`;yT2
z97iv%rVlOZAzEh~-1FWqO$aNkyaLq>*<|?mOs(GR3FT392W{moZ;HD&I)GzNjoj|$
z6#h>D!~{G0fG#7m_{NwN;WBo+FBYH&u^ak!z=N*W+uPe4om4A>NYVy$G_k2Ag|NAO
z1wvW{1B!~LGZRF@(ZG@sG?88UFOlrO7R5%3$!Z0a^39~K+xO1U`7jU^5z(@hy;s>te8_ua9x0Q
zn(l}+Nj+K~g&_``wy#um;Qzq?f&T;l2mTNIANW7;|84Ov|JCpRS8NUz9_W9coCNv_
z?xl52VVa7r#b5F5PRa<1$EH=S_IdUhr^0@&t!&FBRvJ)_Pg&>TFXt
z;Him`;9z20Fs(B_&VW(!)c3M{jzBor(F1Dq}caD#skevw=^xy`W{jSaVH-|RF^
zSxJ<1s$c_lG4y9pCj12Kt805nHipE(fmI(remtK}i2v8umpU5=fE&6Kz!tKfD5{zY
zco!fp1V_e}JZR%cv(4G}(kNtwr>75|O)au*I`|}b#FsjqhIe!NJ-zeaOcKF`RqzgX
zM*JenjN>g8sc(CV9npdUo7l-3T~TbOt`ob-!+y>EHiCg>^;n^+rmplETdVk@A`cVT
zA1`NM{`03FQ?x4Ad8O#s9fGCv7?9O}iuG`+X$PzYMAI#+5>jAk1=DDL4Zw~OY#s>1
zQelFQX}adIQepTSq~Q#Jb(w>Y{qR)gW)Aw04L6*=W|uYVCY8oiUWoVZpBMokVRv`n
z|G@u&{{#OA{tx^g_&@OfZSgOE^Xp%o&t1c5t;L4bTyJavWpxv!`N2~II|QWnuI)Ob
zYv3~hzdJ|?XBxHj0LyR7#yX)CPY)MQMfjp;JB;mJUhwT5L@?^+5I~?-#K5{H_o>s$tlw9%!2JAO%
zwPewi-QXC{!xhKIj#2sjTTl)0}n}@N`7N{W=1DLw7kpe!!Zsa-=pa8*m(NH%XbHdb1Xf#@^W+
z0!Yl(Z&WF*q+t}rJ+X~J$AAkhsNVDQV?(l=i7Q)eikH_fxBDBC;`#gl3*YY74ymO-
zu^WR8?-b)qS)xc+#&MP};#uWZXjqxtS8$~83O9k&BTMF?%87MjbR|K3ytK
zDO-8yV;5vhR^p`+p+(ZmL}s%bYB1U6cA4RPB%6{$xxo07C&85m{tx^g_&@M};Qzq?
jf&T;l-xmM>p8x{@D(Mktb)u`N00000NkvXXu0mjf(?NUb

diff --git a/doc/html-manual/highlight/styles/codepen-embed.css b/doc/html-manual/highlight/styles/codepen-embed.css
deleted file mode 100644
index 195c4a0784..0000000000
--- a/doc/html-manual/highlight/styles/codepen-embed.css
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
-  codepen.io Embed Theme
-  Author: Justin Perry 
-  Original theme - https://github.com/chriskempson/tomorrow-theme
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #222;
-  color: #fff;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #777;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-regexp,
-.hljs-meta,
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-params,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-link,
-.hljs-deletion {
-  color: #ab875d;
-}
-
-.hljs-section,
-.hljs-title,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-type,
-.hljs-attribute {
-  color: #9b869b;
-}
-
-.hljs-string,
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-addition {
-  color: #8f9c6c;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/color-brewer.css b/doc/html-manual/highlight/styles/color-brewer.css
deleted file mode 100644
index 7934d986a7..0000000000
--- a/doc/html-manual/highlight/styles/color-brewer.css
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
-
-Colorbrewer theme
-Original: https://github.com/mbostock/colorbrewer-theme (c) Mike Bostock 
-Ported by Fabrício Tavares de Oliveira
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #fff;
-}
-
-.hljs,
-.hljs-subst {
-  color: #000;
-}
-
-.hljs-string,
-.hljs-meta,
-.hljs-symbol,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-addition {
-  color: #756bb1;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #636363;
-}
-
-.hljs-number,
-.hljs-regexp,
-.hljs-literal,
-.hljs-bullet,
-.hljs-link {
-  color: #31a354;
-}
-
-.hljs-deletion,
-.hljs-variable {
-  color: #88f;
-}
-
-
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-title,
-.hljs-section,
-.hljs-built_in,
-.hljs-doctag,
-.hljs-type,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-strong {
-  color: #3182bd;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-attribute {
-  color: #e6550d;
-}
diff --git a/doc/html-manual/highlight/styles/dark.css b/doc/html-manual/highlight/styles/dark.css
deleted file mode 100644
index b4724f5f50..0000000000
--- a/doc/html-manual/highlight/styles/dark.css
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
-
-Dark style from softwaremaniacs.org (c) Ivan Sagalaev 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #444;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-section,
-.hljs-link {
-  color: white;
-}
-
-.hljs,
-.hljs-subst {
-  color: #ddd;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-name,
-.hljs-type,
-.hljs-attribute,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-built_in,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #d88;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-deletion,
-.hljs-meta {
-  color: #777;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-title,
-.hljs-section,
-.hljs-doctag,
-.hljs-type,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/darkula.css b/doc/html-manual/highlight/styles/darkula.css
deleted file mode 100644
index f4646c3c5d..0000000000
--- a/doc/html-manual/highlight/styles/darkula.css
+++ /dev/null
@@ -1,6 +0,0 @@
-/*
-  Deprecated due to a typo in the name and left here for compatibility purpose only.
-  Please use darcula.css instead.
-*/
-
-@import url('darcula.css');
diff --git a/doc/html-manual/highlight/styles/default.css b/doc/html-manual/highlight/styles/default.css
deleted file mode 100644
index f1bfade31e..0000000000
--- a/doc/html-manual/highlight/styles/default.css
+++ /dev/null
@@ -1,99 +0,0 @@
-/*
-
-Original highlight.js style (c) Ivan Sagalaev 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #F0F0F0;
-}
-
-
-/* Base color: saturation 0; */
-
-.hljs,
-.hljs-subst {
-  color: #444;
-}
-
-.hljs-comment {
-  color: #888888;
-}
-
-.hljs-keyword,
-.hljs-attribute,
-.hljs-selector-tag,
-.hljs-meta-keyword,
-.hljs-doctag,
-.hljs-name {
-  font-weight: bold;
-}
-
-
-/* User color: hue: 0 */
-
-.hljs-type,
-.hljs-string,
-.hljs-number,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-quote,
-.hljs-template-tag,
-.hljs-deletion {
-  color: #880000;
-}
-
-.hljs-title,
-.hljs-section {
-  color: #880000;
-  font-weight: bold;
-}
-
-.hljs-regexp,
-.hljs-symbol,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-link,
-.hljs-selector-attr,
-.hljs-selector-pseudo {
-  color: #BC6060;
-}
-
-
-/* Language color: hue: 90; */
-
-.hljs-literal {
-  color: #78A960;
-}
-
-.hljs-built_in,
-.hljs-bullet,
-.hljs-code,
-.hljs-addition {
-  color: #397300;
-}
-
-
-/* Meta color: hue: 200 */
-
-.hljs-meta {
-  color: #1f7199;
-}
-
-.hljs-meta-string {
-  color: #4d99bf;
-}
-
-
-/* Misc effects */
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/docco.css b/doc/html-manual/highlight/styles/docco.css
deleted file mode 100644
index db366be372..0000000000
--- a/doc/html-manual/highlight/styles/docco.css
+++ /dev/null
@@ -1,97 +0,0 @@
-/*
-Docco style used in http://jashkenas.github.com/docco/ converted by Simon Madine (@thingsinjars)
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  color: #000;
-  background: #f8f8ff;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #408080;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-subst {
-  color: #954121;
-}
-
-.hljs-number {
-  color: #40a070;
-}
-
-.hljs-string,
-.hljs-doctag {
-  color: #219161;
-}
-
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-section,
-.hljs-type {
-  color: #19469d;
-}
-
-.hljs-params {
-  color: #00f;
-}
-
-.hljs-title {
-  color: #458;
-  font-weight: bold;
-}
-
-.hljs-tag,
-.hljs-name,
-.hljs-attribute {
-  color: #000080;
-  font-weight: normal;
-}
-
-.hljs-variable,
-.hljs-template-variable {
-  color: #008080;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #b68;
-}
-
-.hljs-symbol,
-.hljs-bullet {
-  color: #990073;
-}
-
-.hljs-built_in,
-.hljs-builtin-name {
-  color: #0086b3;
-}
-
-.hljs-meta {
-  color: #999;
-  font-weight: bold;
-}
-
-.hljs-deletion {
-  background: #fdd;
-}
-
-.hljs-addition {
-  background: #dfd;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/dracula.css b/doc/html-manual/highlight/styles/dracula.css
deleted file mode 100644
index d591db6801..0000000000
--- a/doc/html-manual/highlight/styles/dracula.css
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
-
-Dracula Theme v1.2.0
-
-https://github.com/zenorocha/dracula-theme
-
-Copyright 2015, All rights reserved
-
-Code licensed under the MIT license
-http://zenorocha.mit-license.org
-
-@author Éverton Ribeiro 
-@author Zeno Rocha 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #282a36;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-section,
-.hljs-link {
-  color: #8be9fd;
-}
-
-.hljs-function .hljs-keyword {
-  color: #ff79c6;
-}
-
-.hljs,
-.hljs-subst {
-  color: #f8f8f2;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-name,
-.hljs-type,
-.hljs-attribute,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #f1fa8c;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-deletion,
-.hljs-meta {
-  color: #6272a4;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-title,
-.hljs-section,
-.hljs-doctag,
-.hljs-type,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/far.css b/doc/html-manual/highlight/styles/far.css
deleted file mode 100644
index 2b3f87b562..0000000000
--- a/doc/html-manual/highlight/styles/far.css
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
-
-FAR Style (c) MajestiC 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #000080;
-}
-
-.hljs,
-.hljs-subst {
-  color: #0ff;
-}
-
-.hljs-string,
-.hljs-attribute,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-addition {
-  color: #ff0;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-section,
-.hljs-type,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-variable {
-  color: #fff;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-doctag,
-.hljs-deletion {
-  color: #888;
-}
-
-.hljs-number,
-.hljs-regexp,
-.hljs-literal,
-.hljs-link {
-  color: #0f0;
-}
-
-.hljs-meta {
-  color: #008080;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-title,
-.hljs-section,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/foundation.css b/doc/html-manual/highlight/styles/foundation.css
deleted file mode 100644
index f1fe64b377..0000000000
--- a/doc/html-manual/highlight/styles/foundation.css
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
-Description: Foundation 4 docs style for highlight.js
-Author: Dan Allen 
-Website: http://foundation.zurb.com/docs/
-Version: 1.0
-Date: 2013-04-02
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #eee; color: black;
-}
-
-.hljs-link,
-.hljs-emphasis,
-.hljs-attribute,
-.hljs-addition {
-  color: #070;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong,
-.hljs-string,
-.hljs-deletion {
-  color: #d14;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-quote,
-.hljs-comment {
-  color: #998;
-  font-style: italic;
-}
-
-.hljs-section,
-.hljs-title {
-  color: #900;
-}
-
-.hljs-class .hljs-title,
-.hljs-type {
-  color: #458;
-}
-
-.hljs-variable,
-.hljs-template-variable {
-  color: #336699;
-}
-
-.hljs-bullet {
-  color: #997700;
-}
-
-.hljs-meta {
-  color: #3344bb;
-}
-
-.hljs-code,
-.hljs-number,
-.hljs-literal,
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #099;
-}
-
-.hljs-regexp {
-  background-color: #fff0ff;
-  color: #880088;
-}
-
-.hljs-symbol {
-  color: #990073;
-}
-
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #007700;
-}
diff --git a/doc/html-manual/highlight/styles/github-gist.css b/doc/html-manual/highlight/styles/github-gist.css
deleted file mode 100644
index 155f0b9160..0000000000
--- a/doc/html-manual/highlight/styles/github-gist.css
+++ /dev/null
@@ -1,71 +0,0 @@
-/**
- * GitHub Gist Theme
- * Author : Louis Barranqueiro - https://github.com/LouisBarranqueiro
- */
-
-.hljs {
-  display: block;
-  background: white;
-  padding: 0.5em;
-  color: #333333;
-  overflow-x: auto;
-}
-
-.hljs-comment,
-.hljs-meta {
-  color: #969896;
-}
-
-.hljs-string,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-strong,
-.hljs-emphasis,
-.hljs-quote {
-  color: #df5000;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-type {
-  color: #a71d5d;
-}
-
-.hljs-literal,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-attribute {
-  color: #0086b3;
-}
-
-.hljs-section,
-.hljs-name {
-  color: #63a35c;
-}
-
-.hljs-tag {
-  color: #333333;
-}
-
-.hljs-title,
-.hljs-attr,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-selector-attr,
-.hljs-selector-pseudo {
-  color: #795da3;
-}
-
-.hljs-addition {
-  color: #55a532;
-  background-color: #eaffea;
-}
-
-.hljs-deletion {
-  color: #bd2c00;
-  background-color: #ffecec;
-}
-
-.hljs-link {
-  text-decoration: underline;
-}
diff --git a/doc/html-manual/highlight/styles/github.css b/doc/html-manual/highlight/styles/github.css
deleted file mode 100644
index 791932b87e..0000000000
--- a/doc/html-manual/highlight/styles/github.css
+++ /dev/null
@@ -1,99 +0,0 @@
-/*
-
-github.com style (c) Vasily Polovnyov 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  color: #333;
-  background: #f8f8f8;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #998;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-subst {
-  color: #333;
-  font-weight: bold;
-}
-
-.hljs-number,
-.hljs-literal,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag .hljs-attr {
-  color: #008080;
-}
-
-.hljs-string,
-.hljs-doctag {
-  color: #d14;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-selector-id {
-  color: #900;
-  font-weight: bold;
-}
-
-.hljs-subst {
-  font-weight: normal;
-}
-
-.hljs-type,
-.hljs-class .hljs-title {
-  color: #458;
-  font-weight: bold;
-}
-
-.hljs-tag,
-.hljs-name,
-.hljs-attribute {
-  color: #000080;
-  font-weight: normal;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #009926;
-}
-
-.hljs-symbol,
-.hljs-bullet {
-  color: #990073;
-}
-
-.hljs-built_in,
-.hljs-builtin-name {
-  color: #0086b3;
-}
-
-.hljs-meta {
-  color: #999;
-  font-weight: bold;
-}
-
-.hljs-deletion {
-  background: #fdd;
-}
-
-.hljs-addition {
-  background: #dfd;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/googlecode.css b/doc/html-manual/highlight/styles/googlecode.css
deleted file mode 100644
index 884ad63538..0000000000
--- a/doc/html-manual/highlight/styles/googlecode.css
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
-
-Google Code style (c) Aahan Krish 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: white;
-  color: black;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #800;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-section,
-.hljs-title,
-.hljs-name {
-  color: #008;
-}
-
-.hljs-variable,
-.hljs-template-variable {
-  color: #660;
-}
-
-.hljs-string,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-regexp {
-  color: #080;
-}
-
-.hljs-literal,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-meta,
-.hljs-number,
-.hljs-link {
-  color: #066;
-}
-
-.hljs-title,
-.hljs-doctag,
-.hljs-type,
-.hljs-attr,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-params {
-  color: #606;
-}
-
-.hljs-attribute,
-.hljs-subst {
-  color: #000;
-}
-
-.hljs-formula {
-  background-color: #eee;
-  font-style: italic;
-}
-
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #9B703F
-}
-
-.hljs-addition {
-  background-color: #baeeba;
-}
-
-.hljs-deletion {
-  background-color: #ffc8bd;
-}
-
-.hljs-doctag,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/grayscale.css b/doc/html-manual/highlight/styles/grayscale.css
deleted file mode 100644
index 5376f34064..0000000000
--- a/doc/html-manual/highlight/styles/grayscale.css
+++ /dev/null
@@ -1,101 +0,0 @@
-/*
-
-grayscale style (c) MY Sun 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  color: #333;
-  background: #fff;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #777;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-subst {
-  color: #333;
-  font-weight: bold;
-}
-
-.hljs-number,
-.hljs-literal {
-  color: #777;
-}
-
-.hljs-string,
-.hljs-doctag,
-.hljs-formula {
-  color: #333;
-  background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAYAAACp8Z5+AAAAJ0lEQVQIW2O8e/fufwYGBgZBQUEQxcCIIfDu3Tuwivfv30NUoAsAALHpFMMLqZlPAAAAAElFTkSuQmCC) repeat;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-selector-id {
-  color: #000;
-  font-weight: bold;
-}
-
-.hljs-subst {
-  font-weight: normal;
-}
-
-.hljs-class .hljs-title,
-.hljs-type,
-.hljs-name {
-  color: #333;
-  font-weight: bold;
-}
-
-.hljs-tag {
-  color: #333;
-}
-
-.hljs-regexp {
-    color: #333;
-    background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAICAYAAADA+m62AAAAPUlEQVQYV2NkQAN37979r6yszIgujiIAU4RNMVwhuiQ6H6wQl3XI4oy4FMHcCJPHcDS6J2A2EqUQpJhohQDexSef15DBCwAAAABJRU5ErkJggg==) repeat;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-link {
-  color: #000;
-  background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAKElEQVQIW2NkQAO7d+/+z4gsBhJwdXVlhAvCBECKwIIwAbhKZBUwBQA6hBpm5efZsgAAAABJRU5ErkJggg==) repeat;
-}
-
-.hljs-built_in,
-.hljs-builtin-name {
-  color: #000;
-  text-decoration: underline;
-}
-
-.hljs-meta {
-  color: #999;
-  font-weight: bold;
-}
-
-.hljs-deletion {
-  color: #fff;
-  background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAADCAYAAABS3WWCAAAAE0lEQVQIW2MMDQ39zzhz5kwIAQAyxweWgUHd1AAAAABJRU5ErkJggg==) repeat;
-}
-
-.hljs-addition {
-  color: #000;
-  background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAkAAAAJCAYAAADgkQYQAAAALUlEQVQYV2N89+7dfwYk8P79ewZBQUFkIQZGOiu6e/cuiptQHAPl0NtNxAQBAM97Oejj3Dg7AAAAAElFTkSuQmCC) repeat;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/gruvbox-dark.css b/doc/html-manual/highlight/styles/gruvbox-dark.css
deleted file mode 100644
index f563811a86..0000000000
--- a/doc/html-manual/highlight/styles/gruvbox-dark.css
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
-
-Gruvbox style (dark) (c) Pavel Pertsev (original style at https://github.com/morhetz/gruvbox)
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #282828;
-}
-
-.hljs,
-.hljs-subst {
-  color: #ebdbb2;
-}
-
-/* Gruvbox Red */
-.hljs-deletion,
-.hljs-formula,
-.hljs-keyword,
-.hljs-link,
-.hljs-selector-tag {
-  color: #fb4934;
-}
-
-/* Gruvbox Blue */
-.hljs-built_in,
-.hljs-emphasis,
-.hljs-name,
-.hljs-quote,
-.hljs-strong,
-.hljs-title,
-.hljs-variable {
-  color: #83a598;
-}
-
-/* Gruvbox Yellow */
-.hljs-attr,
-.hljs-params,
-.hljs-template-tag,
-.hljs-type {
-  color: #fabd2f;
-}
-
-/* Gruvbox Purple */
-.hljs-builtin-name,
-.hljs-doctag,
-.hljs-literal,
-.hljs-number {
-  color: #8f3f71;
-}
-
-/* Gruvbox Orange */
-.hljs-code,
-.hljs-meta,
-.hljs-regexp,
-.hljs-selector-id,
-.hljs-template-variable {
-  color: #fe8019;
-}
-
-/* Gruvbox Green */
-.hljs-addition,
-.hljs-meta-string,
-.hljs-section,
-.hljs-selector-attr,
-.hljs-selector-class,
-.hljs-string,
-.hljs-symbol {
-  color: #b8bb26;
-}
-
-/* Gruvbox Aqua */
-.hljs-attribute,
-.hljs-bullet,
-.hljs-class,
-.hljs-function,
-.hljs-function .hljs-keyword,
-.hljs-meta-keyword,
-.hljs-selector-pseudo,
-.hljs-tag {
-  color: #8ec07c;
-}
-
-/* Gruvbox Gray */
-.hljs-comment {
-  color: #928374;
-}
-
-/* Gruvbox Purple */
-.hljs-link_label,
-.hljs-literal,
-.hljs-number {
-  color: #d3869b;
-}
-
-.hljs-comment,
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-section,
-.hljs-strong,
-.hljs-tag {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/gruvbox-light.css b/doc/html-manual/highlight/styles/gruvbox-light.css
deleted file mode 100644
index ff45468eb2..0000000000
--- a/doc/html-manual/highlight/styles/gruvbox-light.css
+++ /dev/null
@@ -1,108 +0,0 @@
-/*
-
-Gruvbox style (light) (c) Pavel Pertsev (original style at https://github.com/morhetz/gruvbox)
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #fbf1c7;
-}
-
-.hljs,
-.hljs-subst {
-  color: #3c3836;
-}
-
-/* Gruvbox Red */
-.hljs-deletion,
-.hljs-formula,
-.hljs-keyword,
-.hljs-link,
-.hljs-selector-tag {
-  color: #9d0006;
-}
-
-/* Gruvbox Blue */
-.hljs-built_in,
-.hljs-emphasis,
-.hljs-name,
-.hljs-quote,
-.hljs-strong,
-.hljs-title,
-.hljs-variable {
-  color: #076678;
-}
-
-/* Gruvbox Yellow */
-.hljs-attr,
-.hljs-params,
-.hljs-template-tag,
-.hljs-type {
-  color: #b57614;
-}
-
-/* Gruvbox Purple */
-.hljs-builtin-name,
-.hljs-doctag,
-.hljs-literal,
-.hljs-number {
-  color: #8f3f71;
-}
-
-/* Gruvbox Orange */
-.hljs-code,
-.hljs-meta,
-.hljs-regexp,
-.hljs-selector-id,
-.hljs-template-variable {
-  color: #af3a03;
-}
-
-/* Gruvbox Green */
-.hljs-addition,
-.hljs-meta-string,
-.hljs-section,
-.hljs-selector-attr,
-.hljs-selector-class,
-.hljs-string,
-.hljs-symbol {
-  color: #79740e;
-}
-
-/* Gruvbox Aqua */
-.hljs-attribute,
-.hljs-bullet,
-.hljs-class,
-.hljs-function,
-.hljs-function .hljs-keyword,
-.hljs-meta-keyword,
-.hljs-selector-pseudo,
-.hljs-tag {
-  color: #427b58;
-}
-
-/* Gruvbox Gray */
-.hljs-comment {
-  color: #928374;
-}
-
-/* Gruvbox Purple */
-.hljs-link_label,
-.hljs-literal,
-.hljs-number {
-  color: #8f3f71;
-}
-
-.hljs-comment,
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-section,
-.hljs-strong,
-.hljs-tag {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/hopscotch.css b/doc/html-manual/highlight/styles/hopscotch.css
deleted file mode 100644
index 32e60d230a..0000000000
--- a/doc/html-manual/highlight/styles/hopscotch.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * Hopscotch
- * by Jan T. Sott
- * https://github.com/idleberg/Hopscotch
- *
- * This work is licensed under the Creative Commons CC0 1.0 Universal License
- */
-
-/* Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #989498;
-}
-
-/* Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-link,
-.hljs-deletion {
-  color: #dd464c;
-}
-
-/* Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params {
-  color: #fd8b19;
-}
-
-/* Yellow */
-.hljs-class .hljs-title {
-  color: #fdcc59;
-}
-
-/* Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #8fc13e;
-}
-
-/* Aqua */
-.hljs-meta {
-  color: #149b93;
-}
-
-/* Blue */
-.hljs-function,
-.hljs-section,
-.hljs-title {
-  color: #1290bf;
-}
-
-/* Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #c85e7c;
-}
-
-.hljs {
-  display: block;
-  background: #322931;
-  color: #b9b5b8;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/hybrid.css b/doc/html-manual/highlight/styles/hybrid.css
deleted file mode 100644
index 29735a1890..0000000000
--- a/doc/html-manual/highlight/styles/hybrid.css
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
-
-vim-hybrid theme by w0ng (https://github.com/w0ng/vim-hybrid)
-
-*/
-
-/*background color*/
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #1d1f21;
-}
-
-/*selection color*/
-.hljs::selection,
-.hljs span::selection {
-  background: #373b41;
-}
-
-.hljs::-moz-selection,
-.hljs span::-moz-selection {
-  background: #373b41;
-}
-
-/*foreground color*/
-.hljs {
-  color: #c5c8c6;
-}
-
-/*color: fg_yellow*/
-.hljs-title,
-.hljs-name {
-  color: #f0c674;
-}
-
-/*color: fg_comment*/
-.hljs-comment,
-.hljs-meta,
-.hljs-meta .hljs-keyword {
-  color: #707880;
-}
-
-/*color: fg_red*/
-.hljs-number,
-.hljs-symbol,
-.hljs-literal,
-.hljs-deletion,
-.hljs-link {
- color: #cc6666
-}
-
-/*color: fg_green*/
-.hljs-string,
-.hljs-doctag,
-.hljs-addition,
-.hljs-regexp,
-.hljs-selector-attr,
-.hljs-selector-pseudo {
-  color: #b5bd68;
-}
-
-/*color: fg_purple*/
-.hljs-attribute,
-.hljs-code,
-.hljs-selector-id {
- color: #b294bb;
-}
-
-/*color: fg_blue*/
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-bullet,
-.hljs-tag {
- color: #81a2be;
-}
-
-/*color: fg_aqua*/
-.hljs-subst,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #8abeb7;
-}
-
-/*color: fg_orange*/
-.hljs-type,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-quote,
-.hljs-section,
-.hljs-selector-class {
-  color: #de935f;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/idea.css b/doc/html-manual/highlight/styles/idea.css
deleted file mode 100644
index 3bf1892bd4..0000000000
--- a/doc/html-manual/highlight/styles/idea.css
+++ /dev/null
@@ -1,97 +0,0 @@
-/*
-
-Intellij Idea-like styling (c) Vasily Polovnyov 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  color: #000;
-  background: #fff;
-}
-
-.hljs-subst,
-.hljs-title {
-  font-weight: normal;
-  color: #000;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #808080;
-  font-style: italic;
-}
-
-.hljs-meta {
-  color: #808000;
-}
-
-.hljs-tag {
-  background: #efefef;
-}
-
-.hljs-section,
-.hljs-name,
-.hljs-literal,
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-type,
-.hljs-selector-id,
-.hljs-selector-class {
-  font-weight: bold;
-  color: #000080;
-}
-
-.hljs-attribute,
-.hljs-number,
-.hljs-regexp,
-.hljs-link {
-  font-weight: bold;
-  color: #0000ff;
-}
-
-.hljs-number,
-.hljs-regexp,
-.hljs-link {
-  font-weight: normal;
-}
-
-.hljs-string {
-  color: #008000;
-  font-weight: bold;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-formula {
-  color: #000;
-  background: #d0eded;
-  font-style: italic;
-}
-
-.hljs-doctag {
-  text-decoration: underline;
-}
-
-.hljs-variable,
-.hljs-template-variable {
-  color: #660e7a;
-}
-
-.hljs-addition {
-  background: #baeeba;
-}
-
-.hljs-deletion {
-  background: #ffc8bd;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/ir-black.css b/doc/html-manual/highlight/styles/ir-black.css
deleted file mode 100644
index bd4c755ed8..0000000000
--- a/doc/html-manual/highlight/styles/ir-black.css
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
-  IR_Black style (c) Vasily Mikhailitchenko 
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #000;
-  color: #f8f8f8;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-meta {
-  color: #7c7c7c;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-tag,
-.hljs-name {
-  color: #96cbfe;
-}
-
-.hljs-attribute,
-.hljs-selector-id {
-  color: #ffffb6;
-}
-
-.hljs-string,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-addition {
-  color: #a8ff60;
-}
-
-.hljs-subst {
-  color: #daefa3;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #e9c062;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-doctag {
-  color: #ffffb6;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-literal {
-  color: #c6c5fe;
-}
-
-.hljs-number,
-.hljs-deletion {
-  color:#ff73fd;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/kimbie.dark.css b/doc/html-manual/highlight/styles/kimbie.dark.css
deleted file mode 100644
index d139cb5d0c..0000000000
--- a/doc/html-manual/highlight/styles/kimbie.dark.css
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
-    Name:     Kimbie (dark)
-    Author:   Jan T. Sott
-    License:  Creative Commons Attribution-ShareAlike 4.0 Unported License
-    URL:      https://github.com/idleberg/Kimbie-highlight.js
-*/
-
-/* Kimbie Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #d6baad;
-}
-
-/* Kimbie Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-meta {
-  color: #dc3958;
-}
-
-/* Kimbie Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-deletion,
-.hljs-link {
-  color: #f79a32;
-}
-
-/* Kimbie Yellow */
-.hljs-title,
-.hljs-section,
-.hljs-attribute {
-  color: #f06431;
-}
-
-/* Kimbie Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #889b4a;
-}
-
-/* Kimbie Purple */
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-function {
-  color: #98676a;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #221a0f;
-  color: #d3af86;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/kimbie.light.css b/doc/html-manual/highlight/styles/kimbie.light.css
deleted file mode 100644
index 04ff6ed3a2..0000000000
--- a/doc/html-manual/highlight/styles/kimbie.light.css
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
-    Name:     Kimbie (light)
-    Author:   Jan T. Sott
-    License:  Creative Commons Attribution-ShareAlike 4.0 Unported License
-    URL:      https://github.com/idleberg/Kimbie-highlight.js
-*/
-
-/* Kimbie Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #a57a4c;
-}
-
-/* Kimbie Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-meta {
-  color: #dc3958;
-}
-
-/* Kimbie Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-deletion,
-.hljs-link {
-  color: #f79a32;
-}
-
-/* Kimbie Yellow */
-.hljs-title,
-.hljs-section,
-.hljs-attribute {
-  color: #f06431;
-}
-
-/* Kimbie Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #889b4a;
-}
-
-/* Kimbie Purple */
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-function {
-  color: #98676a;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #fbebd4;
-  color: #84613d;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/magula.css b/doc/html-manual/highlight/styles/magula.css
deleted file mode 100644
index 44dee5e8e1..0000000000
--- a/doc/html-manual/highlight/styles/magula.css
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
-Description: Magula style for highligh.js
-Author: Ruslan Keba 
-Website: http://rukeba.com/
-Version: 1.0
-Date: 2009-01-03
-Music: Aphex Twin / Xtal
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background-color: #f4f4f4;
-}
-
-.hljs,
-.hljs-subst {
-  color: black;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-attribute,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #050;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #777;
-}
-
-.hljs-number,
-.hljs-regexp,
-.hljs-literal,
-.hljs-type,
-.hljs-link {
-  color: #800;
-}
-
-.hljs-deletion,
-.hljs-meta {
-  color: #00e;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-built_in,
-.hljs-tag,
-.hljs-name {
-  font-weight: bold;
-  color: navy;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/mono-blue.css b/doc/html-manual/highlight/styles/mono-blue.css
deleted file mode 100644
index 884c97c767..0000000000
--- a/doc/html-manual/highlight/styles/mono-blue.css
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
-  Five-color theme from a single blue hue.
-*/
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #eaeef3;
-}
-
-.hljs {
-  color: #00193a;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-title,
-.hljs-section,
-.hljs-doctag,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-comment {
-  color: #738191;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-section,
-.hljs-built_in,
-.hljs-literal,
-.hljs-type,
-.hljs-addition,
-.hljs-tag,
-.hljs-quote,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #0048ab;
-}
-
-.hljs-meta,
-.hljs-subst,
-.hljs-symbol,
-.hljs-regexp,
-.hljs-attribute,
-.hljs-deletion,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-link,
-.hljs-bullet {
-  color: #4c81c9;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/monokai-sublime.css b/doc/html-manual/highlight/styles/monokai-sublime.css
deleted file mode 100644
index 2864170daf..0000000000
--- a/doc/html-manual/highlight/styles/monokai-sublime.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
-
-Monokai Sublime style. Derived from Monokai by noformnocontent http://nn.mit-license.org/
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #23241f;
-}
-
-.hljs,
-.hljs-tag,
-.hljs-subst {
-  color: #f8f8f2;
-}
-
-.hljs-strong,
-.hljs-emphasis {
-  color: #a8a8a2;
-}
-
-.hljs-bullet,
-.hljs-quote,
-.hljs-number,
-.hljs-regexp,
-.hljs-literal,
-.hljs-link {
-  color: #ae81ff;
-}
-
-.hljs-code,
-.hljs-title,
-.hljs-section,
-.hljs-selector-class {
-  color: #a6e22e;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-name,
-.hljs-attr {
-  color: #f92672;
-}
-
-.hljs-symbol,
-.hljs-attribute {
-  color: #66d9ef;
-}
-
-.hljs-params,
-.hljs-class .hljs-title {
-  color: #f8f8f2;
-}
-
-.hljs-string,
-.hljs-type,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-selector-id,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-variable {
-  color: #e6db74;
-}
-
-.hljs-comment,
-.hljs-deletion,
-.hljs-meta {
-  color: #75715e;
-}
diff --git a/doc/html-manual/highlight/styles/monokai.css b/doc/html-manual/highlight/styles/monokai.css
deleted file mode 100644
index 775d53f91a..0000000000
--- a/doc/html-manual/highlight/styles/monokai.css
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
-Monokai style - ported by Luigi Maselli - http://grigio.org
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #272822; color: #ddd;
-}
-
-.hljs-tag,
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-strong,
-.hljs-name {
-  color: #f92672;
-}
-
-.hljs-code {
-  color: #66d9ef;
-}
-
-.hljs-class .hljs-title {
-  color: white;
-}
-
-.hljs-attribute,
-.hljs-symbol,
-.hljs-regexp,
-.hljs-link {
-  color: #bf79db;
-}
-
-.hljs-string,
-.hljs-bullet,
-.hljs-subst,
-.hljs-title,
-.hljs-section,
-.hljs-emphasis,
-.hljs-type,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #a6e22e;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-deletion,
-.hljs-meta {
-  color: #75715e;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-selector-id {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/obsidian.css b/doc/html-manual/highlight/styles/obsidian.css
deleted file mode 100644
index 356630fa23..0000000000
--- a/doc/html-manual/highlight/styles/obsidian.css
+++ /dev/null
@@ -1,88 +0,0 @@
-/**
- * Obsidian style
- * ported by Alexander Marenin (http://github.com/ioncreature)
- */
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #282b2e;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-selector-id {
-  color: #93c763;
-}
-
-.hljs-number {
-  color: #ffcd22;
-}
-
-.hljs {
-  color: #e0e2e4;
-}
-
-.hljs-attribute {
-  color: #668bb0;
-}
-
-.hljs-code,
-.hljs-class .hljs-title,
-.hljs-section {
-  color: white;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #d39745;
-}
-
-.hljs-meta {
-  color: #557182;
-}
-
-.hljs-tag,
-.hljs-name,
-.hljs-bullet,
-.hljs-subst,
-.hljs-emphasis,
-.hljs-type,
-.hljs-built_in,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable {
-  color: #8cbbad;
-}
-
-.hljs-string,
-.hljs-symbol {
-  color: #ec7600;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-deletion {
-  color: #818e96;
-}
-
-.hljs-selector-class {
-  color: #A082BD
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/paraiso-dark.css b/doc/html-manual/highlight/styles/paraiso-dark.css
deleted file mode 100644
index e7292401c6..0000000000
--- a/doc/html-manual/highlight/styles/paraiso-dark.css
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
-    Paraíso (dark)
-    Created by Jan T. Sott (http://github.com/idleberg)
-    Inspired by the art of Rubens LP (http://www.rubenslp.com.br)
-*/
-
-/* Paraíso Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #8d8687;
-}
-
-/* Paraíso Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-link,
-.hljs-meta {
-  color: #ef6155;
-}
-
-/* Paraíso Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-deletion {
-  color: #f99b15;
-}
-
-/* Paraíso Yellow */
-.hljs-title,
-.hljs-section,
-.hljs-attribute {
-  color: #fec418;
-}
-
-/* Paraíso Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #48b685;
-}
-
-/* Paraíso Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #815ba4;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #2f1e2e;
-  color: #a39e9b;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/paraiso-light.css b/doc/html-manual/highlight/styles/paraiso-light.css
deleted file mode 100644
index 944857cd8d..0000000000
--- a/doc/html-manual/highlight/styles/paraiso-light.css
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
-    Paraíso (light)
-    Created by Jan T. Sott (http://github.com/idleberg)
-    Inspired by the art of Rubens LP (http://www.rubenslp.com.br)
-*/
-
-/* Paraíso Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #776e71;
-}
-
-/* Paraíso Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-link,
-.hljs-meta {
-  color: #ef6155;
-}
-
-/* Paraíso Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-deletion {
-  color: #f99b15;
-}
-
-/* Paraíso Yellow */
-.hljs-title,
-.hljs-section,
-.hljs-attribute {
-  color: #fec418;
-}
-
-/* Paraíso Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #48b685;
-}
-
-/* Paraíso Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #815ba4;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #e7e9db;
-  color: #4f424c;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/pojoaque.css b/doc/html-manual/highlight/styles/pojoaque.css
deleted file mode 100644
index 2e07847b2b..0000000000
--- a/doc/html-manual/highlight/styles/pojoaque.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
-
-Pojoaque Style by Jason Tate
-http://web-cms-designs.com/ftopict-10-pojoaque-style-for-highlight-js-code-highlighter.html
-Based on Solarized Style from http://ethanschoonover.com/solarized
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  color: #dccf8f;
-  background: url(./pojoaque.jpg) repeat scroll left top #181914;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #586e75;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-addition {
-  color: #b64926;
-}
-
-.hljs-number,
-.hljs-string,
-.hljs-doctag,
-.hljs-regexp {
-  color: #468966;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-built_in,
-.hljs-name {
-  color: #ffb03b;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-class .hljs-title,
-.hljs-type,
-.hljs-tag {
-  color: #b58900;
-}
-
-.hljs-attribute {
-  color: #b89859;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-link,
-.hljs-subst,
-.hljs-meta {
-  color: #cb4b16;
-}
-
-.hljs-deletion {
-  color: #dc322f;
-}
-
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #d3a60c;
-}
-
-.hljs-formula {
-  background: #073642;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/pojoaque.jpg b/doc/html-manual/highlight/styles/pojoaque.jpg
deleted file mode 100644
index 9c07d4ab40b6d77e90ff69f0012bcd33b21d31c3..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 1186
zcmZXSe^8Tk9LK-kXFs3)f@f?)Cddzw3v4wdZyXQ;4x3=;Ja*N#%n9ik!UGmt9H3k0
zJST|5jOc(ID$FQt3C?jQZBws#kXolO1lg9Pba9BB=Q+UEBX!nY@6Uhl&+ofe$Q$y5
z@ci`~)&qzDP(lOiQ5p?p
z(`j^e7!yUAVHk%K#^GQXn?s0=VLYCI$HRoe=xCuZ>A6A3@sxEP#XqNFpIb=0)KQ#Nss_tD17;m4@$JKL;LR|K|QF3f%!L5+s(9Ft8SQ
zG|~pGpEGFW5Z|OA)-O@mNHy-g@7m8JTf?kl@vUKBGmw)Y*9sDRNr3PN!IKefWaydTe1D
zjzpyzPnD3}hBNaS4aFX7=0&~I*Hu7#4au@qVBglH#-m;QFOx_`=j
z{EqRY#Eh*yoWP^pa4H>8GH{rO?!_+xwL0(k4yL^D%^nBkJ*UI;Lx;ped8d|f*S_s@
z3~ilcRC(&NT#9Gn#UD;o^EYSMXDMf%XcUi3>;WXXD-QX3P9wMyP7eA&RS{)h5{??W3^Rq=goFJ>?lA~J-
zdYe>!xvYLW*fPT0RK7wsJRg^?x#W1*GP9_f`6t>QD_X>0d!owyN>nO2?U5}|3?hX_UZYT@^>S!9eB~bZ9U`q;`U)@L670o1g
z`Hd}h<_WRvUc|n*%v4Hbb-4tJD40iyF^q%g*&!6>hkYDvi-{Uc4yTM
zzcthN4Z{ka!+F_KzYV#yWi;c^X^q6g`pD8cp?$Kl?hCz0s^a|mH%P!CF%*<6k^~i`
zT5Mi-t5-frUcHkk^Qh}+N)Kz1&Bi95`oNc|quI>tUi~BY>xcF9(%tv2i{G6kE9*q~
qCoAGl20`)w0rdgp9H%Q=M5|p`hOhFz6$I%Y&ncY8>c?7PXyh+SL&XXJ

diff --git a/doc/html-manual/highlight/styles/purebasic.css b/doc/html-manual/highlight/styles/purebasic.css
deleted file mode 100644
index 5ce9b9e071..0000000000
--- a/doc/html-manual/highlight/styles/purebasic.css
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
-
-PureBASIC native IDE style ( version 1.0 - April 2016 )
-
-by Tristano Ajmone 
-
-Public Domain
-
-NOTE_1:	PureBASIC code syntax highlighting only applies the following classes:
-			.hljs-comment
-			.hljs-function
-			.hljs-keywords
-			.hljs-string
-			.hljs-symbol
-
-		Other classes are added here for the benefit of styling other languages with the look and feel of PureBASIC native IDE style.
-		If you need to customize a stylesheet for PureBASIC only, remove all non-relevant classes -- PureBASIC-related classes are followed by
-		a "--- used for PureBASIC ... ---" comment on same line.
-
-NOTE_2:	Color names provided in comments were derived using "Name that Color" online tool:
-			http://chir.ag/projects/name-that-color
-*/
-
-.hljs { /* Common set of rules required by highlight.js (don'r remove!) */
-	display: block;
-	overflow-x: auto;
-	padding: 0.5em;
-	background: #FFFFDF; /* Half and Half (approx.) */
-/* --- Uncomment to add PureBASIC native IDE styled font!
-	font-family: Consolas;
-*/
-}
-
-.hljs, /* --- used for PureBASIC base color --- */
-.hljs-type,  /* --- used for PureBASIC Procedures return type --- */
-.hljs-function, /* --- used for wrapping PureBASIC Procedures definitions --- */
-.hljs-name,
-.hljs-number,
-.hljs-attr,
-.hljs-params,
-.hljs-subst {
-	color: #000000; /* Black */
-}
-
-.hljs-comment, /* --- used for PureBASIC Comments --- */
-.hljs-regexp,
-.hljs-section,
-.hljs-selector-pseudo,
-.hljs-addition {
-	color: #00AAAA; /* Persian Green (approx.) */
-}
-
-.hljs-title, /* --- used for PureBASIC Procedures Names --- */
-.hljs-tag,
-.hljs-variable,
-.hljs-code  {
-	color: #006666; /* Blue Stone (approx.) */
-}
-
-.hljs-keyword, /* --- used for PureBASIC Keywords --- */
-.hljs-class,
-.hljs-meta-keyword,
-.hljs-selector-class,
-.hljs-built_in,
-.hljs-builtin-name {
-	color: #006666; /* Blue Stone (approx.) */
-	font-weight: bold;
-}
-
-.hljs-string, /* --- used for PureBASIC Strings --- */
-.hljs-selector-attr {
-	color: #0080FF; /* Azure Radiance (approx.) */
-}
-
-.hljs-symbol, /* --- used for PureBASIC Constants --- */
-.hljs-link,
-.hljs-deletion,
-.hljs-attribute {
-	color: #924B72; /* Cannon Pink (approx.) */
-}
-
-.hljs-meta,
-.hljs-literal,
-.hljs-selector-id {
-	color: #924B72; /* Cannon Pink (approx.) */
-	font-weight: bold;
-}
-
-.hljs-strong,
-.hljs-name {
-	font-weight: bold;
-}
-
-.hljs-emphasis {
-	font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/qtcreator_dark.css b/doc/html-manual/highlight/styles/qtcreator_dark.css
deleted file mode 100644
index 7aa56a3655..0000000000
--- a/doc/html-manual/highlight/styles/qtcreator_dark.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
-
-Qt Creator dark color scheme
-
-*/
-
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #000000;
-}
-
-.hljs,
-.hljs-subst,
-.hljs-tag,
-.hljs-title {
-  color: #aaaaaa;
-}
-
-.hljs-strong,
-.hljs-emphasis {
-  color: #a8a8a2;
-}
-
-.hljs-bullet,
-.hljs-quote,
-.hljs-number,
-.hljs-regexp,
-.hljs-literal {
-  color: #ff55ff;
-}
-
-.hljs-code
-.hljs-selector-class {
-  color: #aaaaff;
-}
-
-.hljs-emphasis,
-.hljs-stronge,
-.hljs-type {
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-function,
-.hljs-section,
-.hljs-symbol,
-.hljs-name {
-  color: #ffff55;
-}
-
-.hljs-attribute {
-  color: #ff5555;
-}
-
-.hljs-variable,
-.hljs-params,
-.hljs-class .hljs-title {
-  color: #8888ff;
-}
-
-.hljs-string,
-.hljs-selector-id,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-type,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-addition,
-.hljs-link {
-  color: #ff55ff;
-}
-
-.hljs-comment,
-.hljs-meta,
-.hljs-deletion {
-  color: #55ffff;
-}
diff --git a/doc/html-manual/highlight/styles/qtcreator_light.css b/doc/html-manual/highlight/styles/qtcreator_light.css
deleted file mode 100644
index 1efa2c660f..0000000000
--- a/doc/html-manual/highlight/styles/qtcreator_light.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
-
-Qt Creator light color scheme
-
-*/
-
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #ffffff;
-}
-
-.hljs,
-.hljs-subst,
-.hljs-tag,
-.hljs-title {
-  color: #000000;
-}
-
-.hljs-strong,
-.hljs-emphasis {
-  color: #000000;
-}
-
-.hljs-bullet,
-.hljs-quote,
-.hljs-number,
-.hljs-regexp,
-.hljs-literal {
-  color: #000080;
-}
-
-.hljs-code
-.hljs-selector-class {
-  color: #800080;
-}
-
-.hljs-emphasis,
-.hljs-stronge,
-.hljs-type {
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-function,
-.hljs-section,
-.hljs-symbol,
-.hljs-name {
-  color: #808000;
-}
-
-.hljs-attribute {
-  color: #800000;
-}
-
-.hljs-variable,
-.hljs-params,
-.hljs-class .hljs-title {
-  color: #0055AF;
-}
-
-.hljs-string,
-.hljs-selector-id,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-type,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-addition,
-.hljs-link {
-  color: #008000;
-}
-
-.hljs-comment,
-.hljs-meta,
-.hljs-deletion {
-  color: #008000;
-}
diff --git a/doc/html-manual/highlight/styles/railscasts.css b/doc/html-manual/highlight/styles/railscasts.css
deleted file mode 100644
index 008cdc5bf1..0000000000
--- a/doc/html-manual/highlight/styles/railscasts.css
+++ /dev/null
@@ -1,106 +0,0 @@
-/*
-
-Railscasts-like style (c) Visoft, Inc. (Damien White)
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #232323;
-  color: #e6e1dc;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #bc9458;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #c26230;
-}
-
-.hljs-string,
-.hljs-number,
-.hljs-regexp,
-.hljs-variable,
-.hljs-template-variable {
-  color: #a5c261;
-}
-
-.hljs-subst {
-  color: #519f50;
-}
-
-.hljs-tag,
-.hljs-name {
-  color: #e8bf6a;
-}
-
-.hljs-type {
-  color: #da4939;
-}
-
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-attr,
-.hljs-link {
-  color: #6d9cbe;
-}
-
-.hljs-params {
-  color: #d0d0ff;
-}
-
-.hljs-attribute {
-  color: #cda869;
-}
-
-.hljs-meta {
-  color: #9b859d;
-}
-
-.hljs-title,
-.hljs-section {
-  color: #ffc66d;
-}
-
-.hljs-addition {
-  background-color: #144212;
-  color: #e6e1dc;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-deletion {
-  background-color: #600;
-  color: #e6e1dc;
-  display: inline-block;
-  width: 100%;
-}
-
-.hljs-selector-class {
-  color: #9b703f;
-}
-
-.hljs-selector-id {
-  color: #8b98ab;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-link {
-  text-decoration: underline;
-}
diff --git a/doc/html-manual/highlight/styles/rainbow.css b/doc/html-manual/highlight/styles/rainbow.css
deleted file mode 100644
index 905eb8ef18..0000000000
--- a/doc/html-manual/highlight/styles/rainbow.css
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
-
-Style with support for rainbow parens
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #474949;
-  color: #d1d9e1;
-}
-
-
-.hljs-comment,
-.hljs-quote {
-  color: #969896;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-type,
-.hljs-addition {
-  color: #cc99cc;
-}
-
-.hljs-number,
-.hljs-selector-attr,
-.hljs-selector-pseudo {
-  color: #f99157;
-}
-
-.hljs-string,
-.hljs-doctag,
-.hljs-regexp {
-  color: #8abeb7;
-}
-
-.hljs-title,
-.hljs-name,
-.hljs-section,
-.hljs-built_in {
-  color: #b5bd68;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-selector-id,
-.hljs-class .hljs-title {
-   color: #ffcc66;
-}
-
-.hljs-section,
-.hljs-name,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-subst,
-.hljs-meta,
-.hljs-link {
-  color: #f99157;
-}
-
-.hljs-deletion {
-  color: #dc322f;
-}
-
-.hljs-formula {
-  background: #eee8d5;
-}
-
-.hljs-attr,
-.hljs-attribute {
-  color: #81a2be;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/school-book.css b/doc/html-manual/highlight/styles/school-book.css
deleted file mode 100644
index 964b51d841..0000000000
--- a/doc/html-manual/highlight/styles/school-book.css
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
-
-School Book style from goldblog.com.ua (c) Zaripov Yura 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 15px 0.5em 0.5em 30px;
-  font-size: 11px;
-  line-height:16px;
-}
-
-pre{
-  background:#f6f6ae url(./school-book.png);
-  border-top: solid 2px #d2e8b9;
-  border-bottom: solid 1px #d2e8b9;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal {
-  color:#005599;
-  font-weight:bold;
-}
-
-.hljs,
-.hljs-subst {
-  color: #3e5915;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-attribute,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-link {
-  color: #2c009f;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-deletion,
-.hljs-meta {
-  color: #e60415;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-name,
-.hljs-selector-id,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/school-book.png b/doc/html-manual/highlight/styles/school-book.png
deleted file mode 100644
index 956e9790a0e2c079b3d568348ff3accd1d9cac30..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 486
zcmeAS@N?(olHy`uVBq!ia0y~yV7?7x3vjRjNjAS6Ga$v1?&#~tz_9*=IcwKTAYZb?
zHKHUqKdq!Zu_%?nF(p4KRlzeiF+DXXH8G{K@MNkD0|R4)r;B4q#jQ7Ycl#YS5MfK$
z?b^fh#qmaEhFDxvyThwfhdfkOPApt1lr{NA;Vr%uzxJuVIyzm(ed_8_-0$LLU})H&o5Re&aDemE>EG#(|F^t9_pa-H
z_Mf?rMVrs}-M?S|?ZdY@c6s41zy8~}@a{v&#Ea7V)wJ$+#K|u$5UvWCdFLwGac}6w{_s*=8A6L7Rfc|9gboFyt
I=akR{0OLZ+qyPW_

diff --git a/doc/html-manual/highlight/styles/solarized-dark.css b/doc/html-manual/highlight/styles/solarized-dark.css
deleted file mode 100644
index b4c0da1f78..0000000000
--- a/doc/html-manual/highlight/styles/solarized-dark.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
-
-Orginal Style from ethanschoonover.com/solarized (c) Jeremy Hull 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #002b36;
-  color: #839496;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #586e75;
-}
-
-/* Solarized Green */
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-addition {
-  color: #859900;
-}
-
-/* Solarized Cyan */
-.hljs-number,
-.hljs-string,
-.hljs-meta .hljs-meta-string,
-.hljs-literal,
-.hljs-doctag,
-.hljs-regexp {
-  color: #2aa198;
-}
-
-/* Solarized Blue */
-.hljs-title,
-.hljs-section,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #268bd2;
-}
-
-/* Solarized Yellow */
-.hljs-attribute,
-.hljs-attr,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-class .hljs-title,
-.hljs-type {
-  color: #b58900;
-}
-
-/* Solarized Orange */
-.hljs-symbol,
-.hljs-bullet,
-.hljs-subst,
-.hljs-meta,
-.hljs-meta .hljs-keyword,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-link {
-  color: #cb4b16;
-}
-
-/* Solarized Red */
-.hljs-built_in,
-.hljs-deletion {
-  color: #dc322f;
-}
-
-.hljs-formula {
-  background: #073642;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/solarized-light.css b/doc/html-manual/highlight/styles/solarized-light.css
deleted file mode 100644
index fdcfcc72c4..0000000000
--- a/doc/html-manual/highlight/styles/solarized-light.css
+++ /dev/null
@@ -1,84 +0,0 @@
-/*
-
-Orginal Style from ethanschoonover.com/solarized (c) Jeremy Hull 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #fdf6e3;
-  color: #657b83;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #93a1a1;
-}
-
-/* Solarized Green */
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-addition {
-  color: #859900;
-}
-
-/* Solarized Cyan */
-.hljs-number,
-.hljs-string,
-.hljs-meta .hljs-meta-string,
-.hljs-literal,
-.hljs-doctag,
-.hljs-regexp {
-  color: #2aa198;
-}
-
-/* Solarized Blue */
-.hljs-title,
-.hljs-section,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #268bd2;
-}
-
-/* Solarized Yellow */
-.hljs-attribute,
-.hljs-attr,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-class .hljs-title,
-.hljs-type {
-  color: #b58900;
-}
-
-/* Solarized Orange */
-.hljs-symbol,
-.hljs-bullet,
-.hljs-subst,
-.hljs-meta,
-.hljs-meta .hljs-keyword,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-link {
-  color: #cb4b16;
-}
-
-/* Solarized Red */
-.hljs-built_in,
-.hljs-deletion {
-  color: #dc322f;
-}
-
-.hljs-formula {
-  background: #eee8d5;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/sunburst.css b/doc/html-manual/highlight/styles/sunburst.css
deleted file mode 100644
index f56dd5e9b6..0000000000
--- a/doc/html-manual/highlight/styles/sunburst.css
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
-
-Sunburst-like style (c) Vasily Polovnyov 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #000;
-  color: #f8f8f8;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #aeaeae;
-  font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-type {
-  color: #e28964;
-}
-
-.hljs-string {
-  color: #65b042;
-}
-
-.hljs-subst {
-  color: #daefa3;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #e9c062;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-tag,
-.hljs-name {
-  color: #89bdff;
-}
-
-.hljs-class .hljs-title,
-.hljs-doctag {
-  text-decoration: underline;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-number {
-  color: #3387cc;
-}
-
-.hljs-params,
-.hljs-variable,
-.hljs-template-variable {
-  color: #3e87e3;
-}
-
-.hljs-attribute {
-  color: #cda869;
-}
-
-.hljs-meta {
-  color: #8996a8;
-}
-
-.hljs-formula {
-  background-color: #0e2231;
-  color: #f8f8f8;
-  font-style: italic;
-}
-
-.hljs-addition {
-  background-color: #253b22;
-  color: #f8f8f8;
-}
-
-.hljs-deletion {
-  background-color: #420e09;
-  color: #f8f8f8;
-}
-
-.hljs-selector-class {
-  color: #9b703f;
-}
-
-.hljs-selector-id {
-  color: #8b98ab;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/tomorrow-night-blue.css b/doc/html-manual/highlight/styles/tomorrow-night-blue.css
deleted file mode 100644
index 78e59cc8cb..0000000000
--- a/doc/html-manual/highlight/styles/tomorrow-night-blue.css
+++ /dev/null
@@ -1,75 +0,0 @@
-/* Tomorrow Night Blue Theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-/* Original theme - https://github.com/chriskempson/tomorrow-theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-
-/* Tomorrow Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #7285b7;
-}
-
-/* Tomorrow Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-deletion {
-  color: #ff9da4;
-}
-
-/* Tomorrow Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-meta,
-.hljs-link {
-  color: #ffc58f;
-}
-
-/* Tomorrow Yellow */
-.hljs-attribute {
-  color: #ffeead;
-}
-
-/* Tomorrow Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #d1f1a9;
-}
-
-/* Tomorrow Blue */
-.hljs-title,
-.hljs-section {
-  color: #bbdaff;
-}
-
-/* Tomorrow Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #ebbbff;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #002451;
-  color: white;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/tomorrow-night-bright.css b/doc/html-manual/highlight/styles/tomorrow-night-bright.css
deleted file mode 100644
index e05af8ae24..0000000000
--- a/doc/html-manual/highlight/styles/tomorrow-night-bright.css
+++ /dev/null
@@ -1,74 +0,0 @@
-/* Tomorrow Night Bright Theme */
-/* Original theme - https://github.com/chriskempson/tomorrow-theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-
-/* Tomorrow Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #969896;
-}
-
-/* Tomorrow Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-deletion {
-  color: #d54e53;
-}
-
-/* Tomorrow Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-meta,
-.hljs-link {
-  color: #e78c45;
-}
-
-/* Tomorrow Yellow */
-.hljs-attribute {
-  color: #e7c547;
-}
-
-/* Tomorrow Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #b9ca4a;
-}
-
-/* Tomorrow Blue */
-.hljs-title,
-.hljs-section {
-  color: #7aa6da;
-}
-
-/* Tomorrow Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #c397d8;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: black;
-  color: #eaeaea;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/tomorrow-night-eighties.css b/doc/html-manual/highlight/styles/tomorrow-night-eighties.css
deleted file mode 100644
index 08fd51c742..0000000000
--- a/doc/html-manual/highlight/styles/tomorrow-night-eighties.css
+++ /dev/null
@@ -1,74 +0,0 @@
-/* Tomorrow Night Eighties Theme */
-/* Original theme - https://github.com/chriskempson/tomorrow-theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-
-/* Tomorrow Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #999999;
-}
-
-/* Tomorrow Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-deletion {
-  color: #f2777a;
-}
-
-/* Tomorrow Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-meta,
-.hljs-link {
-  color: #f99157;
-}
-
-/* Tomorrow Yellow */
-.hljs-attribute {
-  color: #ffcc66;
-}
-
-/* Tomorrow Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #99cc99;
-}
-
-/* Tomorrow Blue */
-.hljs-title,
-.hljs-section {
-  color: #6699cc;
-}
-
-/* Tomorrow Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #cc99cc;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #2d2d2d;
-  color: #cccccc;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/tomorrow-night.css b/doc/html-manual/highlight/styles/tomorrow-night.css
deleted file mode 100644
index ddd270a4e7..0000000000
--- a/doc/html-manual/highlight/styles/tomorrow-night.css
+++ /dev/null
@@ -1,75 +0,0 @@
-/* Tomorrow Night Theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-/* Original theme - https://github.com/chriskempson/tomorrow-theme */
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-
-/* Tomorrow Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #969896;
-}
-
-/* Tomorrow Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-deletion {
-  color: #cc6666;
-}
-
-/* Tomorrow Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-meta,
-.hljs-link {
-  color: #de935f;
-}
-
-/* Tomorrow Yellow */
-.hljs-attribute {
-  color: #f0c674;
-}
-
-/* Tomorrow Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #b5bd68;
-}
-
-/* Tomorrow Blue */
-.hljs-title,
-.hljs-section {
-  color: #81a2be;
-}
-
-/* Tomorrow Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #b294bb;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: #1d1f21;
-  color: #c5c8c6;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/tomorrow.css b/doc/html-manual/highlight/styles/tomorrow.css
deleted file mode 100644
index 026a62fe3b..0000000000
--- a/doc/html-manual/highlight/styles/tomorrow.css
+++ /dev/null
@@ -1,72 +0,0 @@
-/* http://jmblog.github.com/color-themes-for-google-code-highlightjs */
-
-/* Tomorrow Comment */
-.hljs-comment,
-.hljs-quote {
-  color: #8e908c;
-}
-
-/* Tomorrow Red */
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-regexp,
-.hljs-deletion {
-  color: #c82829;
-}
-
-/* Tomorrow Orange */
-.hljs-number,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-literal,
-.hljs-type,
-.hljs-params,
-.hljs-meta,
-.hljs-link {
-  color: #f5871f;
-}
-
-/* Tomorrow Yellow */
-.hljs-attribute {
-  color: #eab700;
-}
-
-/* Tomorrow Green */
-.hljs-string,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-addition {
-  color: #718c00;
-}
-
-/* Tomorrow Blue */
-.hljs-title,
-.hljs-section {
-  color: #4271ae;
-}
-
-/* Tomorrow Purple */
-.hljs-keyword,
-.hljs-selector-tag {
-  color: #8959a8;
-}
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  background: white;
-  color: #4d4d4c;
-  padding: 0.5em;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/vs.css b/doc/html-manual/highlight/styles/vs.css
deleted file mode 100644
index c5d07d3115..0000000000
--- a/doc/html-manual/highlight/styles/vs.css
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
-
-Visual Studio-like style based on original C# coloring by Jason Diamond 
-
-*/
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: white;
-  color: black;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-variable {
-  color: #008000;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-built_in,
-.hljs-name,
-.hljs-tag {
-  color: #00f;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-section,
-.hljs-attribute,
-.hljs-literal,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-type,
-.hljs-addition {
-  color: #a31515;
-}
-
-.hljs-deletion,
-.hljs-selector-attr,
-.hljs-selector-pseudo,
-.hljs-meta {
-  color: #2b91af;
-}
-
-.hljs-doctag {
-  color: #808080;
-}
-
-.hljs-attr {
-  color: #f00;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-link {
-  color: #00b0e8;
-}
-
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/highlight/styles/xcode.css b/doc/html-manual/highlight/styles/xcode.css
deleted file mode 100644
index 43dddad84d..0000000000
--- a/doc/html-manual/highlight/styles/xcode.css
+++ /dev/null
@@ -1,93 +0,0 @@
-/*
-
-XCode style (c) Angel Garcia 
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #fff;
-  color: black;
-}
-
-.hljs-comment,
-.hljs-quote {
-  color: #006a00;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal {
-  color: #aa0d91;
-}
-
-.hljs-name {
-  color: #008;
-}
-
-.hljs-variable,
-.hljs-template-variable {
-  color: #660;
-}
-
-.hljs-string {
-  color: #c41a16;
-}
-
-.hljs-regexp,
-.hljs-link {
-  color: #080;
-}
-
-.hljs-title,
-.hljs-tag,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-number,
-.hljs-meta {
-  color: #1c00cf;
-}
-
-.hljs-section,
-.hljs-class .hljs-title,
-.hljs-type,
-.hljs-attr,
-.hljs-built_in,
-.hljs-builtin-name,
-.hljs-params {
-  color: #5c2699;
-}
-
-.hljs-attribute,
-.hljs-subst {
-  color: #000;
-}
-
-.hljs-formula {
-  background-color: #eee;
-  font-style: italic;
-}
-
-.hljs-addition {
-  background-color: #baeeba;
-}
-
-.hljs-deletion {
-  background-color: #ffc8bd;
-}
-
-.hljs-selector-id,
-.hljs-selector-class {
-  color: #9b703f;
-}
-
-.hljs-doctag,
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
diff --git a/doc/html-manual/highlight/styles/xt256.css b/doc/html-manual/highlight/styles/xt256.css
deleted file mode 100644
index 58df82cb75..0000000000
--- a/doc/html-manual/highlight/styles/xt256.css
+++ /dev/null
@@ -1,92 +0,0 @@
-
-/*
-  xt256.css
-
-  Contact: initbar [at] protonmail [dot] ch
-         : github.com/initbar
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  color: #eaeaea;
-  background: #000;
-  padding: 0.5;
-}
-
-.hljs-subst {
-  color: #eaeaea;
-}
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
-
-.hljs-builtin-name,
-.hljs-type {
-  color: #eaeaea;
-}
-
-.hljs-params {
-  color: #da0000;
-}
-
-.hljs-literal,
-.hljs-number,
-.hljs-name {
-  color: #ff0000;
-  font-weight: bolder;
-}
-
-.hljs-comment {
-  color: #969896;
-}
-
-.hljs-selector-id,
-.hljs-quote {
-  color: #00ffff;
-}
-
-.hljs-template-variable,
-.hljs-variable,
-.hljs-title {
-  color: #00ffff;
-  font-weight: bold;
-}
-
-.hljs-selector-class,
-.hljs-keyword,
-.hljs-symbol {
-  color: #fff000;
-}
-
-.hljs-string,
-.hljs-bullet {
-  color: #00ff00;
-}
-
-.hljs-tag,
-.hljs-section {
-  color: #000fff;
-}
-
-.hljs-selector-tag {
-  color: #000fff;
-  font-weight: bold;
-}
-
-.hljs-attribute,
-.hljs-built_in,
-.hljs-regexp,
-.hljs-link {
-  color: #ff00ff;
-}
-
-.hljs-meta {
-  color: #fff;
-  font-weight: bolder;
-}
diff --git a/doc/html-manual/highlight/styles/zenburn.css b/doc/html-manual/highlight/styles/zenburn.css
deleted file mode 100644
index 07be502016..0000000000
--- a/doc/html-manual/highlight/styles/zenburn.css
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
-
-Zenburn style from voldmar.ru (c) Vladimir Epifanov 
-based on dark.css by Ivan Sagalaev
-
-*/
-
-.hljs {
-  display: block;
-  overflow-x: auto;
-  padding: 0.5em;
-  background: #3f3f3f;
-  color: #dcdcdc;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-tag {
-  color: #e3ceab;
-}
-
-.hljs-template-tag {
-  color: #dcdcdc;
-}
-
-.hljs-number {
-  color: #8cd0d3;
-}
-
-.hljs-variable,
-.hljs-template-variable,
-.hljs-attribute {
-  color: #efdcbc;
-}
-
-.hljs-literal {
-  color: #efefaf;
-}
-
-.hljs-subst {
-  color: #8f8f8f;
-}
-
-.hljs-title,
-.hljs-name,
-.hljs-selector-id,
-.hljs-selector-class,
-.hljs-section,
-.hljs-type {
-  color: #efef8f;
-}
-
-.hljs-symbol,
-.hljs-bullet,
-.hljs-link {
-  color: #dca3a3;
-}
-
-.hljs-deletion,
-.hljs-string,
-.hljs-built_in,
-.hljs-builtin-name {
-  color: #cc9393;
-}
-
-.hljs-addition,
-.hljs-comment,
-.hljs-quote,
-.hljs-meta {
-  color: #7f9f7f;
-}
-
-
-.hljs-emphasis {
-  font-style: italic;
-}
-
-.hljs-strong {
-  font-weight: bold;
-}
diff --git a/doc/html-manual/hwsw-inputs.shtml b/doc/html-manual/hwsw-inputs.shtml
deleted file mode 100644
index f1ffdbbeec..0000000000
--- a/doc/html-manual/hwsw-inputs.shtml
+++ /dev/null
@@ -1,106 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
Hardware and Software Equivalence and Co-Verification

-
-
Synchronizing Inputs

-
-
Driving Primary Inputs

-
-

-The examples in the tutorial are trivial
-in the sense that the model has only one possible trace. The
-initial state is deterministic, and there is only one possible transition,
-so the verification problem can be solved by testing a single run. In contrast,
-consider the following Verilog module:
-

-
-
module top(input clk, input i);
-
-  reg [3:0] counter;
-
-  initial counter=0;
-
-  always @(posedge clk)
-    if(i)
-      counter=counter+1;
-
-endmodule
-

-
-

-The module above has an input named i. The top-level inputs
-of the Verilog design have to be generated by the C program.
-This is done by assigning the desired values to the corresponding struct
-member, and then calling the set_inputs() function
-before calling next_timeframe().
-Consider the following example:
-

-
-
void next_timeframe();
-void set_inputs();
-extern const unsigned int bound;
-
-struct module_top {
-  unsigned int counter;
-  _Bool i;
-};
-
-extern struct module_top top;
-
-int main() {
-  assert(top.counter==0);
-
-  top.i=1;
-  set_inputs(); next_timeframe();
-  assert(top.counter==1);
-
-  top.i=1;
-  set_inputs(); next_timeframe();
-  assert(top.counter==2);
-
-  top.i=0;
-  set_inputs(); next_timeframe();
-  assert(top.counter==2);
-}
-

-
-

-As an example, consider a
-Verilog module that has a signal reset as an input, which is
-active-low. The following C fragment drives this input to be active in the
-first cycle, and not active in any subsequent cycle:
-

-
-
  top.resetn=0;
-  set_inputs(); next_timeframe();
-
-  for(i=1; i<bound; i++) {
-    top.resetn=1;
-    set_inputs(); next_timeframe();
-  }
-

-
-

-Note that the value of the input must be set before
-calling next_timeframe(). The effect of the
-input values on values derived in a combinatorial way
-is immediately visible. The effect on clocked values
-becomes visible in the next time frame.
-

-
-
Using Nondeterminism

-
-

-The examples above use particular, constant values to drive the primary
-inputs.  In order to check the behavior of the Verilog model for more than
-one specific input, use nondeterminism.
-

-
-
-
diff --git a/doc/html-manual/hwsw-mapping.shtml b/doc/html-manual/hwsw-mapping.shtml
deleted file mode 100644
index 6c953dd28c..0000000000
--- a/doc/html-manual/hwsw-mapping.shtml
+++ /dev/null
@@ -1,131 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
Hardware and Software Equivalence and Co-Verification

-
-
Mapping Variables

-
-
Mapping Variables within the Module Hierarchy

-
-

-Verilog modules are hierarchical. The extern declarations shown above
-only allow reading the values of signals and registers that are in the top
-module. In order to read values from sub-modules, CBMC uses structures.
-

-
-

-As an example, consider the following Verilog file
-(hierarchy.v):
-

-
-
module counter(input clk, input [7:0] increment);
-
-  reg [7:0] counter;
-
-  initial counter=0;
-
-  always @(posedge clk)
-    counter=counter+increment;
-
-endmodule
-
-module top(input clk);
-
-  counter c1(clk, 1);
-  counter c2(clk, 2);
-
-endmodule
-

-
-

-The file has two modules: a top module and a counter module. The counter
-module is instantiated twice within the top module. A reference to the
-register counter within the C program would be ambiguous, as the two
-module instances have separate instances of the register. CBMC and SATABS
-use the following data structures for this example:
-

-
-
void next_timeframe();
-extern const unsigned int bound;
-
-struct counter {
-  unsigned char increment;
-  unsigned char counter;
-};
-
-struct module_top {
-  struct module_counter c1, c2;
-};
-
-extern struct module_top top;
-
-int main() {
-  next_timeframe();
-  next_timeframe();
-  next_timeframe();
-  assert(top.c1.counter==3);
-  assert(top.c2.counter==6);
-}
-

-
-

-The main function reads both counter values for cycle 3. A deeper
-hierarchy (modules in modules) is realized by using additional structure
-members. Writing these data structures for large Verilog designs is error
-prone, and thus, HW-CBMC can generate them automatically. The declarations
-above are generated using the command line
-

-
-

-
-hw-cbmc --gen-interface --module top hierarchy.v
-
-

-
-
Mapping Verilog Vectors to Arrays or Scalars

-
-

-In Verilog, a definition such as
-

-
-
-  wire [31:0] x;
-
-
-

-can be used for arithmetic (as in x+10) and as array of Booleans
-(as in x[2]). ANSI-C does not allow both, so when mapping variables
-from Verilog to C, the user has to choose one option for each such variable.
-As an example, the C declaration
-

-
-
-  unsigned int x;
-
-
-

-will allow using x in arithmetic expressions, while the C declaration
-

-
-
-  __CPROVER_bool x[32];
-
-
-

-will allow accessing the individual bits of x using the syntax
-x[bit].  The --gen-interface option of HW-CBMC
-will generate the first variant if the vector has the same size as one of
-the standard integer types, and will use the __CPROVER_bitvector[] type if
-not so.  This choice can be changed by adjusting the declaration
-accordingly.  Note that both SpecC and SystemC offer bit-extraction
-operators, which means that it unnecessary to use the declaration as array
-in order to access individual bits of a vector.
-

-
-
-
diff --git a/doc/html-manual/hwsw-tutorial.shtml b/doc/html-manual/hwsw-tutorial.shtml
deleted file mode 100644
index bda1953759..0000000000
--- a/doc/html-manual/hwsw-tutorial.shtml
+++ /dev/null
@@ -1,220 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
Hardware and Software Equivalence and Co-Verification

-
-
A Small Tutorial

-
-
Verilog vs. ANSI-C

-
-

-We assume that CBMC is installed on your system. If not so, follow
-these instructions.

-
-

-The following Verilog module implements a 4-bit counter
-(counter.v):
-

-
-
module top(input clk);
-
-  reg [3:0] counter;
-
-  initial counter=0;
-
-  always @(posedge clk)
-    counter=counter+1;
-
-endmodule
-

-
-

-HW-CBMC can take Verilog modules as the one above as additional input. Similar
-as in co-simulation, the data in the Verilog modules is available to the C
-program by means of global variables. For the example above, the following C
-fragment shows the definition of the variable that holds the value
-of the counter register:
-

-
-
struct module_top {
-  unsigned int counter;
-};
-
-extern struct module_top top;
-

-
-

-Using this definition, the value of the counter register in the
-Verilog fragment above can be accessed as top.counter. Please note
-that the name of the variable must match the name of the top module.
-The C program only has a view of one state of the Verilog model. The Verilog
-model makes a transition once the function next_timeframe() is
-called.
-

-
-

-As CBMC performs Bounded Model Checking, the number of timeframes available
-for analysis must be bounded (SATABS
-has no such restriction). As it is
-desirable to change the bound to adjust it to the available computing
-capacity, the bound is given on the command line and not as part of the C
-program. This makes it easy to use only one C program for arbitrary bounds.
-The actual bound is available in the C program using the following
-declaration:
-

-
-
-extern const unsigned int bound;
-
-
-

-Also note that the fragment above declares a constant variable of struct
-type. Thus, the C program can only read the trace values and is not able to
-modify them. We will later on describe how to drive inputs of the Verilog
-module from within the C program.
-

-
-

-As described in previous chapters, assertions can be used to verify
-properties of the Verilog trace. As an example, the following program checks
-two values of the trace of the counter module
-(counter.c):
-

-
-
void next_timeframe();
-
-struct module_top {
-  unsigned int counter;
-};
-
-extern struct module_top top;
-
-int main() {
-  next_timeframe();
-  next_timeframe();
-  assert(top.counter==2);
-  next_timeframe();
-  assert(top.counter==3);
-}
-

-
-

-The following CBMC command line checks these assertions with a bound of
-20:
-

-
-

-
-hw-cbmc counter.c counter.v --module top --bound 20
-
-

-
-

-Note that a specific version of CBMC is used, called hw-cbmc.
-The module name given must match the name of the module in the Verilog
-file. Multiple Verilog files can be given on the command line.
-

-
-

-The --bound parameter is not to be confused with the --unwind
-parameter. While the --unwind parameter specifies the maximum
-unwinding depth for loops within the C program, the --bound parameter
-specifies the number of times the transition relation of the Verilog module
-is to be unwound.
-

-
-
Counterexamples

-
-

-For the given example, the verification is successful. If the first
-assertion is changed to
-

-
-
-  assert(top.counter==10);
-
-
-

-and the bound on the command line is changed to 6, CBMC will produce a
-counterexample. CBMC produces two traces: One for the C program, which
-matches the traces described earlier, and a separate trace for the Verilog
-module. The values of the registers in the Verilog module are also shown in
-the C trace as part of the initial state.
-

-
-
-Initial State

-----------------------------------------------------

-  bound=6 (00000000000000000000000000000110)

-  counter={ 0, 1, 2, 3, 4, 5, 6 }

-

-Failed assertion: assertion line 6 function main

-

-Transition system state 0

-----------------------------------------------------

-  counter=0 (0000)

-

-Transition system state 1

-----------------------------------------------------

-  counter=1 (0001)

-

-Transition system state 2

-----------------------------------------------------

-  counter=2 (0010)

-

-Transition system state 3

-----------------------------------------------------

-  counter=3 (0011)

-

-Transition system state 4

-----------------------------------------------------

-  counter=4 (0100)

-

-Transition system state 5

-----------------------------------------------------

-  counter=5 (0101)

-

-Transition system state 6

-----------------------------------------------------

-  counter=6 (0110)
-
-
-
Using the Bound

-
-

-The following program is using the bound variable to check the counter value
-in all cycles:
-

-
-
void next_timeframe();
-extern const unsigned int bound;
-
-struct module_top {
-  unsigned int counter;
-};
-
-extern struct module_top top;
-
-int main() {
-  unsigned cycle;
-
-  for(cycle=0; cycle<bound; cycle++) {
-    assert(top.counter==(cycle & 15));
-    next_timeframe();
-  }
-}
-

-
-

-CBMC performs bounds checking, and restricts the number of times that
-next_timeframe() can be called. SATABS does not re­quire a bound,
-and thus, next_timeframe() can be called arbitrarily many times.
-

-
-
-
diff --git a/doc/html-manual/hwsw.shtml b/doc/html-manual/hwsw.shtml
deleted file mode 100644
index 88fba4e5fe..0000000000
--- a/doc/html-manual/hwsw.shtml
+++ /dev/null
@@ -1,116 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Hardware and Software Equivalence and Co-Verification

-
-
Introduction

-
-

-A common hardware design approach employed by many companies is to first
-write a quick prototype that behaves like the planned circuit in a language
-like ANSI-C. This program is then used for extensive testing and debugging,
-in particular of any embedded software that will later on be shipped with
-the circuit. An example is the hardware of a cell phone and its software.
-After testing and debugging of the program, the actual hardware design is
-written using hardware description languages like
-VHDL or
-Verilog.
-

-
-

-Thus, there are two implementations of the same design: one written in
-ANSI-C, which is written for simulation, and one written in register
-transfer level HDL, which is the actual product. The ANSI-C implementation
-is usually thoroughly tested and debugged.
-

-
-

-Due to market constraints, companies aim to sell the chip as soon as
-possible, i.e., shortly after the HDL implementation is designed. There is
-usually little time for additional debugging and testing of the HDL
-implementation. Thus, an automated, or nearly automated way of establishing
-the consistency of the HDL implementation is highly desirable.
-

-
-

-This motivates the verification problem: we want to verify the consistency
-of the HDL implementation, i.e., the product,
-
-using the ANSI-C implementation as a reference. Es­ta­bli­shing the consistency
-does not re­quire a formal specification. However, formal methods to verify
-either the hardware or software design are still desirable.
-

-
-
Related Work

-
-

-There have been several attempts in the past to tackle the problem. 
-
-Semeria et al. describe a tool for verifying the combinational equivalence of
-RTL-C and an HDL.  They translate the C code into HDL and use
-standard equivalence checkers to establish the equivalence.  The C code has
-to be very close to a hardware description (RTL level), which implies that
-the source and target have to be implemented in a very similar way.  There
-are also variants of C specifically for this purpose.  The SystemC standard defines a
-subset of C++ that can be used for synthesis.  Further
-variants of ANSI-C for specifying hardware are SpecC and Handel C, among
-others.

-
-

-The concept of verifying the equivalence of a software implementation and a
-synchronous transition system was introduced by
-Pnueli, Siegel, and
-Shtrichman. The C program is re­quired to be in a very
-specific form, since a mechanical translation is assumed.
-

-
-

-In 2000, 
-Currie, Hu, and Rajan transform DSP assembly language
-into an equation for the Stanford Validity Checker.
-The symbolic execution of programs for comparison with RTL is now
-common practice.
-

-
-

-The previous work focuses on a small subset of ANSI-C that is particularly
-close to register transfer language. Thus, the designer is often re­quired to
-rewrite the C program manually in order to comply with these constraints. We
-extend the methodology to handle the full set of ANSI-C language features.
-This is a challenge in the presence of complex, dynamic data structures and
-pointers that may dynamically point to multiple objects. Furthermore, our
-methodology allows arbitrary loop constructs.
-

-
-
Further Material

-
-
We provide a small 
-tutorial and a description on 
-how to synchronize inputs between the C model and the Verilog model.
-There is also a collection of 
-benchmark problems available.
-

-
-

-
Further Reading

-
-
-
 
-
-
-
diff --git a/doc/html-manual/index.shtml b/doc/html-manual/index.shtml
deleted file mode 100644
index 1e5690411f..0000000000
--- a/doc/html-manual/index.shtml
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-
Table of Contents

-
-
1. Introduction

-
-
2. Installation

-

-CBMC,
-SATABS,
-Eclipse plugin
-

-
-
3. CBMC – Bounded Model Checking

-
-

-A Short Tutorial,
-Loop Unwinding,
-Test Suite Generation
-

-
-
4. SATABS – Predicate Abstraction
-with SAT

-
-

-Introduction,
-Background,
-Tutorials
-

-
-
5. Modeling

-
-

-Nondeterminism,
-Assumptions and Assertions,
-Pointers,
-Floating Point
-

-
-
6. Hardware/Software Co-Verification

-
-

-Introduction,
-Tutorial,
-Mapping Variables,
-Synchronizing Inputs
-

-
-
7. Build Systems, Libraries and Instrumentation

-
-

-Introduction,
-Integration into Build Systems with goto-cc,
-Visual Studio Builds,
-Variants of goto-cc,
-Architectural Settings,
-Property Instrumentation
-with goto-instrument,
-The CPROVER API Reference
-

-
-
diff --git a/doc/html-manual/installation-cbmc.shtml b/doc/html-manual/installation-cbmc.shtml
deleted file mode 100644
index 2ee1a8df0e..0000000000
--- a/doc/html-manual/installation-cbmc.shtml
+++ /dev/null
@@ -1,80 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Installing CBMC

-
-
Requirements

-
-

-CBMC is available for Windows, i86 Linux, and MacOS X. 
-CBMC requires a code pre-processing environment comprising of a
-suitable preprocessor and an a set of header files.

-
-
    
-
-
  1. 
-Linux: the preprocessor and the header files typically come with a
-package called gcc, which must be installed prior to the installation
-of CBMC.
-
    2. 
-
-
  2. 
-Windows: The Windows version of CBMC requires the preprocessor 
-cl.exe, which is part of Microsoft Visual Studio. We recommend
-the free Visual
-Studio Community 2013.
-
    3. 
-
-
  3. 
-MacOS: Install the
-XCode Command Line Utilities
-prior to installing CBMC. Just installing XCode alone is not enough.
-
    4. 
-
-

-
-

-Important note for Windows users: Visual Studio's
-cl.exe relies on a
-complex set of environment variables to identify the target architecture and
-the directories that contain the header files.
-You must run CBMC
-from within the Visual Studio Command Prompt.
-

-
-

-Note that the distribution files for the
-Eclipse plugin include the
-CBMC executable.  Therefore, if you intend to run CBMC
-exclusively within Eclipse, you can skip the installation of the
-CBMC executable.  However, you still have to install the compiler
-environment as described above.

-
-
Installing the CBMC Binaries

-
-
    
-
  1. Download CBMC for your operating system.
-The binaries are available from 
-http://www.cprover.org/cbmc/.
-
    2. 
-
-
  2. Unzip/untar the archive into a directory of your choice. 
-We recommend to add this directory to your PATH environment
-variable.
    3. 
-
-

-
-

-You are now ready to use CBMC!

-
-
Building CBMC from Source

-
-

-Alternatively, the CBMC source code is available via SVN.
-To compile the source code, follow
-these instructions.
-

-
-
-
diff --git a/doc/html-manual/installation-plugin.shtml b/doc/html-manual/installation-plugin.shtml
deleted file mode 100644
index 39e32cfe1b..0000000000
--- a/doc/html-manual/installation-plugin.shtml
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Installing the Eclipse Plugin

-
-
Requirements

-
-

-We provide a graphical user interface to CBMC and SATABS, which is
-realized as a plugin to the Eclipse framework.  Eclipse is available at http://www.eclipse.org.  We do not provide
-installation instructions for Eclipse (basically, you only have to download
-the current version and extract the files to your hard-disk) and assume that
-you have already installed the current version.

-
-

-CBMC and SATABS have their own requirements.  As an example, both CBMC
-and SATABS require a suitable preprocessor and a set of header files.  As
-first step, you should therefore follow the installation instructions for CBMC and SATABS.
-
-

-Important note for Windows users: Visual Studio's
-cl.exe relies on a
-complex set of environment variables to identify the target architecture and
-the directories that contain the header files.
-You must run Eclipse from within the
-Visual Studio Command Prompt.
-

-
-
Installing the Eclipse Plugin

-
-

-The installation instructions for the Eclipse Plugin, including the
-link to the download site, are available 
-here. This includes a small tutorial on how to use the Eclipse plugin.
-

-
-
-
diff --git a/doc/html-manual/installation-satabs.shtml b/doc/html-manual/installation-satabs.shtml
deleted file mode 100644
index 46ca303bd6..0000000000
--- a/doc/html-manual/installation-satabs.shtml
+++ /dev/null
@@ -1,139 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Installing SATABS

-
-
Requirements

-
-

-SATABS is available for Windows, i86 Linux, and MacOS X. 
-SATABS requires a code pre-processing environment comprising of a
-suitable preprocessor and an a set of header files.

-
-
    
-
-
  1. Linux: the preprocessor and the header files typically come with a
-package called gcc, which must be installed prior to the installation
-of SATABS.
    2. 
-
-
  2. Windows: The Windows version of SATABS requires the preprocessor 
-cl.exe, which is part of Visual Studio (including
-the free Visual
-Studio Express).
    3. 
-
-
  3. MacOS: Install XCode
-prior to installing SATABS.
    4. 
-
-

-
-

-Important note for Windows users: Visual Studio's
-cl.exe relies on a
-complex set of environment variables to identify the target architecture and
-the directories that contain the header files.
-You must run SATABS
-from within the Visual Studio Command Prompt.
-

-
-

-Note that the distribution files for the
-Eclipse plugin include the
-command-line tools.  Therefore, if you intend to run SATABS
-exclusively within Eclipse, you can skip the installation of the
-command-line tools.  However, you still have to install the compiler
-environment as described above.

-
-
Choosing and Installing a Model Checker

-
-You need to install a Model Checker in order to be able
-to run SATABS. You can choose between following alternatives:
-
    
-
  • 
-Cadence SMV.
-Available from 
-http://www.kenmcmil.com/smv.html.
-Cadence SMV is a commercial model checker. The free version
-that is available on the homepage above must not be used for
-commercial purposes (read the license agreement thoroughly
-before you download the tool).
-The documentation for SMV can be found in the directory where 
-you unzip/untar SMV under ./smv/doc/smv/. Read the installation
-instructions carefully. The Linux/MacOS versions require
-setting environment variables. You must add
-add the directory containing the smv binary
-(located in ./smv/bin/, relative to the path where you
-unpacked it) to your PATH environment variable.
-SATABS uses Cadence SMV by default.
    
-
    • 
-
-
  • 
-NuSMV. Available from
-http://nusmv.irst.itc.it/.
-NuSMV is the open source alternative to Cadence SMV. Installation
-instructions and documentation can be found on the NuSMV homepage.
-The directory containing the NuSMV binary should be added
-to your PATH environment variable.
-Use the option
    
-
-
    
---modelchecker nusmv
-
    
-
-
    
-to instruct SATABS to use NuSMV.
    
-
    • 
-
-
  • 
-BOPPO. Available from 
-http://www.cprover.org/boppo/.
-BOPPO is a model checker that uses SAT-solving algorithms.
-BOPPO relies on a built-in SAT solver and Quantor, a solver
-for quantified boolean formulas that is currently bundled
-with BOPPO, but also available separately from
-http://fmv.jku.at/quantor/.
-We recommend to add the directories containing both tools to your
-PATH environment variable.
-Use the option
    
-
-
    
---modelchecker boppo
-
    
-
-
    
-when you call SATABS and want it to use BOPPO instead of SMV.
-
    
-
    • 
-
-
  • 
-BOOM. Available from 
-http://www.cprover.org/boom/. Boom has a number of unique features,
-including the verification of programs with unbounded thread creation.
-
    
-
    • 
-
-

-
-
Installing SATABS

-
-
    
-
  1. Download SATABS for your operating system.
-The binaries are available from 
-http://www.cprover.org/satabs/.
-
    2. 
-
-
  2. Unzip/untar the archive into a directory of your choice. 
-We recommend to add this directory to your PATH environment
-variable.
    3. 
-
-

-
-

-Now you can execute SATABS. Try running SATABS
-on the small examples presented in the 
-tutorial section. If you use the Cadence SMV model checker, the only
-command line arguments you have to specify are the names
-of the files that contain your program.
-

-
-
diff --git a/doc/html-manual/introduction.shtml b/doc/html-manual/introduction.shtml
deleted file mode 100644
index 687e056484..0000000000
--- a/doc/html-manual/introduction.shtml
+++ /dev/null
@@ -1,162 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Introduction

-
-
Motivation

-
-

-Numerous tools to hunt down functional design flaws in silicon have
-been available for many years, mainly due to the enormous cost of hardware
-bugs. The use of such tools is wide-spread. In contrast, the market
-for tools that address the need for quality software is still in its
-infancy.

-
-

-Research in software quality has an enormous breadth.
-We focus the presentation using two criteria:

-
-
    
-
-
  1. 
-We believe that any form of quality requires a specific
-guarantee, in theory and practice.
    2. 
-
-
  2. The sheer size of software designs requires techniques that
-are highly automated.
    3. 
-
-

-
-

-In practice, quality guarantees usually do not refer to "total
-correctness" of a design, as ensuring the absence of all bugs is too
-expensive for most applications. In contrast, a guarantee of the
-absence of specific flaws is achievable, and is a good metric of
-quality.

-
-

-We document two programs that try to achieve formal guarantees of
-the absence of specific problems: CBMC and SATABS. The algorithms
-implemented by CBMC and SATABS are complementary, and often, one tool
-is able to solve a problem that the other cannot solve.

-
-

-Both CBMC and SATABS are verification tools for ANSI-C/C++ programs. They
-verify array bounds (buffer overflows), pointer safety, exceptions and
-user-specified assertions. Both tools model integer arithmetic accurately,
-and are able to reason about machine-level artifacts such as integer
-overflow. CBMC and SATABS are therefore able to detect a class of bugs that
-has so far gone unnoticed by many other verification tools. This manual
-also covers some variants of CBMC, which includes HW-CBMC
-for hardware/software co-verification.

-
-
Bounded Model Checking with CBMC

-
-

-CBMC implements a technique called Bounded Model Checking (BMC). In
-BMC, the transition relation for a complex state machine and its
-specification are jointly unwound to obtain a Boolean formula, which is then
-checked for satisfiability by using an efficient SAT procedure. If the
-formula is satisfiable, a counterexample is extracted from the output of the
-SAT procedure. If the formula is not satisfiable, the program can be unwound
-more to determine if a longer counterexample exists.

-
-

-In many engineering domains, real-time guarantees are a strict requirement.
-An example is software embedded in automotive controllers. As a consequence,
-the loop constructs in these types of programs often have a strict bound
-on the number of iterations. CBMC is able to formally verify such bounds
-by means of unwinding assertions. Once this bound is established,
-CBMC is able to prove the absence of errors.

-
-

-A more detailed description of how to apply CBMC verify programs is
-here.

-
-
Automatic Program Verification with SATABS

-
-

-In many cases, lightweight properties such as array bounds do not rely on
-the entire program. A large fraction of the program is irrelevant to
-the property. SATABS exploits this observation and computes an
-abstraction of the program in order to handle large amounts of code.
-

-
-

-In order to use SATABS it is not necessary to understand the abstraction
-refinement process. For the interested reader, a high-level introduction
-to abstraction refinement is provided
-here. We also provide
-tutorials on how to use SATABS.
-

-
-

-Just as CBMC, SATABS attempts to build counterexamples that refute the
-property. If such a counterexample is found, it is presented to the engineer
-to facilitate localization and repair of the program.
-

-
-

-
Example: Buffer Overflows

-
-

-In order to give a brief overview of the capabilities of CBMC and SATABS we
-start with a small example.
-The issue of buffer
-overflows has obtained wide public attention.  A
-buffer is a contiguously-allocated chunk of memory, represented by an array or
-a pointer in C.  Programs written in C do not provide automatic bounds
-checking on the buffer, which means a program can – accidentally or
-maliciously – write past a buffer.  The following example is a perfectly
-valid C program (in the sense that a compiler compiles it without any
-errors):

-
-
-int main() {

-  int buffer[10];

-  buffer[20] = 10;

-}
-
-

-However, the write access to an address outside the allocated memory
-region can lead to unexpected behavior.  In particular, such bugs can be
-exploited to overwrite the return address of a function, thus enabling the
-execution of arbitrary user-induced code.  CBMC and SATABS are able to
-detect this problem and reports that the "upper bound property" of the
-buffer is violated.  CBMC and SATABS are capable of checking these lower and
-upper bounds, even for arrays with dynamic size. A detailed discussion
-of the properties that CBMC and SATABS can check automatically
-is here.

-

-
-
Hardware/Software Co-Verification

-
-

-Software programs often interact with hardware in a non-trivial manner, and
-many properties of the overall design only arise from the interplay of both
-components. CBMC and SATABS therefore support Co-Verification,
-i.e., are able to reason about a C/C++ program together with a circuit
-description given in Verilog.

-
-

-These co-verification capabilities can also be applied to perform refinement
-proofs. Software programs are often used as high-level descriptions of
-circuitry. While both describe the same functionality, the hardware
-implementation usually contains more detail. It is highly desirable to
-establish some form for equivalence between the two descriptions.
-Hardware/Software co-verification and equivalence checking with CBMC and
-SATABS are described here.
-

-
-

-
Further Reading

-
-

-
-
-
diff --git a/doc/html-manual/libraries.shtml b/doc/html-manual/libraries.shtml
deleted file mode 100644
index 7ea2fe1bff..0000000000
--- a/doc/html-manual/libraries.shtml
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Build Systems and Libraries

-
-
The Problem

-
-

-Similar to unit testing, the model checking approach requires 
-the user to clearly define what parts of the program should
-be tested and what the behavior of these parts is.
-This requirement has following reasons:
-

-
-
    
-  
-
  •  Despite recent advances, the size of the programs that
-    model checkers can cope with is still restricted.
-
    • 
-  
-
  •  Typically, you want to verify your program and
-    not the libraries or the operating that it uses (the correctness of these
-    libraries and the OS us usually addressed separately).
-
    • 
-  
-
  •  CBMC and SATABS cannot verify binary libraries. 
-
    • 
-  
-
  •  CBMC and SATABS does not provide a
-    model for the hardware
-    (e.g., hard disk, input/output devices) the tested program
-    runs on. Since CBMC and SATABS are supposed to examine the
-    behavior of the tested program for all possible inputs
-    and outputs, it is reasonable to model input and output
-    by means of non-deterministic choice.
-
    • 
-
-

-
-
Further Reading

-
-

-Existing software projects usually do not come in a single source file that
-may simply be passed to a model checker, but is a collection of files held
-together by a build system. The ex­trac­tion of models from such
-a build system using goto-cc is described here.
-The ap­pli­ca­tion of goto-cc to the entire Linux kernel is described
-here. The problem of architectural
-pa­ram­e­ters (word with, endianness) is explained
-here.
-

-
-
diff --git a/doc/html-manual/modeling-assertions.shtml b/doc/html-manual/modeling-assertions.shtml
deleted file mode 100644
index 19ef6e65d1..0000000000
--- a/doc/html-manual/modeling-assertions.shtml
+++ /dev/null
@@ -1,152 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
Modeling with Assertions and Assumptions

-
-
Assertions

-
-
Assertions
-are statements within the program that attempt to capture the programmer's
-intent.  The ANSI-C standard defines a header file assert.h, which offers a
-macro assert(cond). When executing a statement such
-as

-
-
  assert(p!=NULL);
-

-
-
the execution is aborted with an error message if the
-condition evaluates to false, i.e., if p is NULL in the
-example above.  The CPROVER tools can check the validity of the
-programmer-annotated assertions statically.  Specifically, the CPROVER tools
-will check that the assertions hold for any nondeterministic choice
-that the program can make.  The static assertion checks can be disabled
-using the --no-assertions command line option.

-
-
In addition, there is a CPROVER-specific way
-to specify assertions, using the built-in function __CPROVER_assert:

-
-
  __CPROVER_assert(p!=NULL, "p is not NULL");
-

-
-
The (mandatory) string that is passed as the
-second argument provides an informal description of the assertion.
-It is shown in the list of properties together with the condition.

-
-
The assertion language of the CPROVER tools is
-identical to the language used for expressions.  Note that nondeterminism can be exploited in order
-to check a range of choices.  As an example, the following code fragment
-asserts that all elements of the array are zero:
-

-
-
  int a[100], i;
-
-  ...
-
-  i=nondet_uint();
-  if(i>=0 && i<100)
-    assert(a[i]==0);
-

-
-
The nondeterministic choice will guess the
-element of the array that is nonzero. The code fragment above
-is therefore equivalent to
-

-
-
  int a[100], i;
-
-  ...
-
-  for(i=0; i<100; i++)
-    assert(a[i]==0);
-

-
-
Future CPROVER releases will
-support explicit quantifiers with a syntax that resembles Spec#:
-

-
-
-

-__CPROVER_forall { type identifier ; expression }

-__CPROVER_exists { type identifier ; expression }
-

-
-
-
Assumptions

-
-
Assumptions are used to restrict nondeterministic
-choices made by the program. As an example, suppose we wish to model
-a nondeterministic choice that returns a number from 1 to 100. There
-is no integer type with this range. We therefore use __CPROVER_assume
-to restrict the range of a nondeterministically chosen integer:

-
-
unsigned int nondet_uint();
-
-unsigned int one_to_hundred()
-{
-  unsigned int result=nondet_uint();
-  __CPROVER_assume(result>=1 && result<=100);
-  return result;
-}

-
-
The function above returns the desired integer from 1
-to 100.  You must ensure that the condition given as
-an assumption is actually satisfiable by some nondeterministic choice, or
-otherwise the model checking step will pass vacuously.

-
-
Also note that assumptions are never retroactive: They
-only affect assertions (or other properties) that follow them in program
-order. This is best illustrated with an example. In the following fragment,
-the assumption has no effect on the assertion, which means that
-the assertion will fail:
-

-
-
  x=nondet_uint();
-  assert(x==100);
-  __CPROVER_assume(x==100);
-

-
-

-Assumptions do restrict the search space, but only for assertions that follow.
-As an example, the following program will pass:

-
-
int main() {
-  int x;
-
-  __CPROVER_assume(x>=1 && x<=100000);
-
-  x*=-1;
-
-  __CPROVER_assert(x<0, "x is negative");
-}
-

-
-
Beware that nondeterminism cannot be used to obtain
-the effect of universal quantification in assumptions. As an example,
-

-
-
int main() {
-  int a[10], x, y;
-
-  x=nondet_int();
-  y=nondet_int();
-  __CPROVER_assume(x>=0 && x<10 && y>=0 && y<10);
-
-  __CPROVER_assume(a[x]>=0);
-
-  assert(a[y]>=0);
-}
-

-
-
fails, as there is a choice of x and y which
-results in a counterexample (any choice in which x and y are different).
-

-
-
diff --git a/doc/html-manual/modeling-floating-point.shtml b/doc/html-manual/modeling-floating-point.shtml
deleted file mode 100644
index 8c0cdbeec4..0000000000
--- a/doc/html-manual/modeling-floating-point.shtml
+++ /dev/null
@@ -1,140 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Floating Point

-
-
The CPROVER tools support bit-accurate reasoning about
-  IEEE-754 floating-point and fixed-point arithmetic.  The C standard
-  contains a number of areas of implementation-defined behaviour with regard
-  to floating-point arithmetic:

-
-
    
-
-
  • 
-  CPROVER supports C99 Appendix F, and thus,
-  the __STD_IEC_559__ macro is defined.  This means that
-  the C float data type maps to IEEE
-  754 binary32 and double maps
-  to binary64 and operations on them are as specified in
-  IEEE 754.
    • 
-
-
  • 
-  long double can be configured to
-  be binary64, binary128 (quad precision) or
-  a 96 bit type with 15 exponent bits and 80 significant bits.  The
-  last is an approximation of Intel's x87 extended precision double data
-  type.  As the C standard allows a implementations a fairly wide set
-  of options for long double, it is best avoided for both
-  portable code and bit-precise analysis.  The default is to match the
-  build architecture as closely as possible.
-  
    • 
-
-
  • 
-  In CPROVER, floating-point expressions are evaluated at the
-  'natural precision' (the greatest of the arguments) and not at a
-  higher precision.  This corresponds to FLT_EVAL_METHOD
-  set to 0.  Note that this is a different policy to
-  some platforms (see below).
-  
    • 
-
-
  • 
-  Expression contraction (for example, converting x * y +
-  c to fma(x,y,c)) is not performed.  In effect,
-  the FP_CONTRACT pragma is always off.
-  
    • 
-
-
  • 
-  Constant expressions are evaluated at `run' time wherever possible
-  and so will respect changes in the rounding mode.  In effect,
-  the FENV_ACCESS pragma is always off.  Note that
-  floating point constants are treated as doubles (unless they are
-  followed by f when they are float) as specified in the
-  C standard.  goto-cc
-  supports -fsingle-precision-constant, which allows the
-  (non-standard) treatment of constants as floats.
-  
    • 
-
-
  • 
-  Casts from int to float and float to float make use of the current
-  rounding mode.  Note that the standard requires that casts from
-  float to int use round-to-zero (i.e. truncation).
-  
    • 
-

-
-
x86 and Other Platform-specific Issues

-
-
Not all platforms have the same implementation-defined
-  behaviour as CPROVER.  This can cause mismatches between the verification
-  environment and the execution environment.  If this occurs, check the
-  compiler manual for the choices listed above.  There are two common cases
-  that can cause these problems: 32-bit x86 code and the use of unsafe
-  optimisations.

-
-
Many compilers that target 32-bit x86 platforms
-  employ a different evaluation method.  The extended precision
-  format of the x87 unit is used for all computations regardless of
-  their native precision.  Most of the time, this results in more
-  accurate results and avoids edge cases.  However, it can result in
-  some obscure and difficult to debug behaviour.  Checking
-  if the FLT_EVAL_METHOD macro is non-zero (for these
-  platforms it will typically be 2), should warn of these problems.
-  Changing the compiler flags to use the SSE registers will resolve
-  many of them, give a more standards-compliant platform and will
-  likely perform better.  Thus it is highly recommended.
-  Use -msse2 -mfpmath=sse to enable this option for
-  GCC.  Visual C++ does not have an option to force the exclusive use
-  of SSE instructions, but /arch:SSE2 will pick SSE
-  instructions "when it [the compiler] determines that it is faster to
-  use the SSE/SSE2 instructions" and is thus better
-  than /arch:IA32, which exclusively uses the x87 unit.

-
-
The other common cause of discrepancy between
-  CPROVER results and the actual platform are the use of unsafe
-  optimisations.  Some higher optimisation levels enable
-  transformations that are unsound with respect to the IEEE-754
-  standard.  Consult the compiler manual and disable any
-  optimisations that are described as unsafe (for
-  example, the GCC options -ffast-math).
-  The options -ffp-contract=off (which replaces
-  -mno-fused-madd), -frounding-math
-  and -fsignaling-nans are needed for GCC to be strictly
-  compliant with IEEE-754.

-
-
Rounding Mode

-
-
CPROVER supports the four rounding modes given by
-  IEEE-754 1985; round to nearest (ties to even), round up, round
-  down and round towards zero.  By default, round to nearest is used.
-  However, command line options (--round-to-zero, etc.) can
-  be used to over-ride this.  If more control is needed, CPROVER has
-  models of fesetround (for POSIX systems)
-  and _controlfp (for Windows), which can be used to change
-  the rounding mode during program execution. Furthermore,
-  the inline assembly commands fstcw/fnstcw/fldcw (on x86) can
-  be used.

-
-
The rounding mode is stored in the (thread local)
-  variable __CPROVER_rounding_mode, but users are strongly advised
-  not to use this directly.

-
-
Math Library

-
-
CPROVER implements some of math.h,
-  including fabs, fpclassify
-  and signbit.  It has very limited support for
-  elementary functions.  Care must be taken when verifying properties
-  that are dependent on these functions as the accuracy of
-  implementations can vary considerably.  The C compilers can (and
-  many do) say that the accuracy of these functions is unknown.

-
-
Fixed-point Arithmetic

-
-
CPROVER also has support for fixed-point types.
-  The --fixedbv flag
-  switches float, double and long
-  double to fixed-point types.  The length of these types is
-  platform specific.  The upper half of each type is the integer
-  component and the lower half is the fractional part.

-
-
diff --git a/doc/html-manual/modeling-nondet.shtml b/doc/html-manual/modeling-nondet.shtml
deleted file mode 100644
index 3b0809ffb7..0000000000
--- a/doc/html-manual/modeling-nondet.shtml
+++ /dev/null
@@ -1,65 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Nondeterminism

-
-
Rationale

-
-
Programs typically read inputs from an environment. 
-These inputs can take the form of data read from a file, keyboard or network
-socket, or arguments passed on the command line.  It is usually desirable to
-analyze the program for any choice of these inputs.  In Model Checking,
-inputs are therefore modeled by means of nondeterminism, which means
-that the value of the input is not specified. The program may follow any
-computation that results from any choice of inputs.

-
-
Sources of Nondeterminism

-
-
The CPROVER tools support the following sources of nondeterminism:

-
-
    
-
  • functions that read inputs from the environments;
    • 
-
  • the thread schedule in concurrent programs;
    • 
-
  • initial values of local-scoped variables and memory allocated with
-malloc;
    • 
-
  • initial values of variables that are extern in all
-compilation units;
    • 
-
  • explicit functions for generating nondeterminism.
    • 
-

-
-
The CPROVER tools are shipped with a number of stubs
-for the most commonly used library functions. When executing a statement
-such as getchar(), a nondeterministic value is chosen instead
-of reading a character from the keyboard.
-
-
When desired, nondeterminism can be introduced
-explicitly into the program by means of functions that begin with the
-prefix nondet_. As an example, the following function
-returns a nondeterministically chosen unsigned short int:
-

-
-
unsigned short int nondet_ushortint();
-

-
-
Note that the body of the function is not defined.  The
-name of the function itself is irrelevant (save for the prefix), but must be
-unique.  Also note that a nondeterministic choice is not to be confused with
-a probabilistic (or random) choice.

-
-
Uninterpreted Functions

-
-
It may be necessary to check parts of a program
-independently. Nondeterminism can be used to over-approximate the
-behaviour of part of the system which is not being checked.  Rather
-than calling a complex or unrelated function, a nondeterministic stub
-is used. However, separate calls to the function can return different
-results, even for the same inputs.  If the function output only
-depends on its inputs then this can introduce spurious errors.  To
-avoid this problem, functions whose names begin with the
-prefix __CPROVER_uninterpreted_ are treated as
-uninterpreted functions.  Their value is non-deterministic but different
-invocations will return the same value if their inputs are the same.
-Note that uninterpreted functions are not supported by all back-end solvers.

-
-
diff --git a/doc/html-manual/modeling-pointers.shtml b/doc/html-manual/modeling-pointers.shtml
deleted file mode 100644
index fb3a506cf8..0000000000
--- a/doc/html-manual/modeling-pointers.shtml
+++ /dev/null
@@ -1,108 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
Pointer Model

-
-
Pointers in C

-
-
C programs (and sometimes C++ programs as well) make
-intensive use of pointers in order to decouple program code from specific
-data.  A pointer variable does not store data such as numbers or letters,
-but instead points to a location in memory that hold the relevant data.
-This section describes the way the CPROVER tools model pointers.
-

-
-
Objects and Offsets

-
-
The CPROVER tools represent pointers as a pair.  The
-first member of the pair is the object the pointer points to, and the
-second is the offset within the object.

-
-
In C, objects are simply continuous fragments of memory
-(this definition of "object" is not to be confused with the use of the term
-in object-oriented programming).  Variables of any type are guaranteed to be
-stored as one object, irrespectively of their type.  As an example, all
-members of a struct or array belong to the same object.  CPROVER simply
-assigns a number to each active object.  The object number of a pointer
-p can be extracted using the expression
-__CPROVER_POINTER_OBJECT(p).  As a consequence, pointers to
-different objects are always different, which is not sound.
-
-

-
-
The offset (the second member of the pair that forms a
-pointer) is relative to the beginning of the object; it uses byte
-granularity. As an example, the code fragment
-

-
-
  unsigned array[10];
-  char *p;
-
-  p=(char *)(array+1);
-  p++;
-

-
-
will result in a pointer with offset 5. The offset of
-a pointer p can be extracted using the expression
-__CPROVER_POINTER_OFFSET(p).

-
-
Dereferencing Pointers

-
-
The CPROVER tools require that pointers that
-are dereferenced point to a valid object. Assertions that check
-this requirement can be generated using the option --pointer-check
-and, if desired, --bounds-check. These options will ensure
-that NULL pointers are not dereferenced, and that dynamically
-allocated objects have not yet been deallocated.

-
-
Furthermore, the CPROVER
-tools check that dynamically allocated memory is not
-deallocated twice. The goto-instrument tool is also able
-to add checks for memory leaks, i.e., it detects dynamically
-allocated objects that are not deallocated once the program
-terminates.

-
-
The CPROVER tools support pointer typecasts.  Most
-casts are supported, with the following exceptions:
-

-
-
    
-
  1. 
-One notable exception is that pointers can only be
-accessed using a pointer type.  The conversion of a pointer into an
-integer-type using a pointer typecast is not supported.
-
    2. 
-
-
  2. 
-Casts from integers to pointers yield a pointer that is either
-NULL (if the integer is zero) or that point into a special
-array for modeling 
-memory-mapped I/O. Such pointers are assumed not to
-overlap with any other objects. This is, of course, only sound if
-a corresponding range check is instrumented.
-
    3. 
-
-
  3. 
-Accesses to arrays via pointers that have the array subtype need
-to be well-aligned.
-
    4. 
-
-

-
-
Pointers in Open Programs

-
-
It is frequently desired to validate an open program,
-i.e., a fragment of a program. Some variables are left undefined. In case
-an undefined pointer is dereferenced, CBMC assumes that the pointer
-points to a separate object of appropriate type with unbounded size.
-The object is assumed not to alias with any other object.
-This assumption may obviously be wrong in specific extensions
-of the program.
-

-
-
diff --git a/doc/html-manual/pid_test_suites.xml b/doc/html-manual/pid_test_suites.xml
deleted file mode 100644
index 014fea1229..0000000000
--- a/doc/html-manual/pid_test_suites.xml
+++ /dev/null
@@ -1,500 +0,0 @@
-
-
-CBMC 5.5
-
-  CBMC version 5.5 64-bit x86_64 macos
-
-
-
-  Parsing pid.c
-
-
-
-  Converting
-
-
-
-  Type-checking pid
-
-
-
-  
-  function `nondet_float' is not declared
-
-
-
-  Generating GOTO Program
-
-
-
-  Adding CPROVER library (x86_64)
-
-
-
-  Removal of function pointers and virtual functions
-
-
-
-  Partial Inlining
-
-
-
-  Generic Property Instrumentation
-
-
-criterion: mcdc
-
-
-  Instrumenting coverage goals
-
-
-
-  Starting Bounded Model Checking
-
-
-
-  Unwinding loop main.0 iteration 1 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  Unwinding loop main.0 iteration 2 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  Unwinding loop main.0 iteration 3 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  Unwinding loop main.0 iteration 4 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  Unwinding loop main.0 iteration 5 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  Not unwinding loop main.0 iteration 6 (6 max) file pid.c line 56 function main thread 0
-
-
-
-  size of program expression: 416 steps
-
-
-
-  Generated 114 VCC(s), 108 remaining after simplification
-
-
-
-  Passing problem to propositional reduction
-
-
-
-  converting SSA
-
-
-
-  Aiming to cover 19 goal(s)
-
-
-
-  Running propositional reduction
-
-
-
-  Post-processing
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 553801 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered decision/condition `1 != 0' true
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 395675 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered MC/DC independence condition `!(pprz >= (float)0) && pprz <= (float)(16 * 600)'
-
-
-
-  Covered decision `pprz >= (float)0 && pprz <= (float)(16 * 600)' false
-
-
-
-  Covered condition `pprz >= (float)0' false
-
-
-
-  Covered decision/condition `pprz > (float)(16 * 600)' false
-
-
-
-  Covered condition `pprz <= (float)(16 * 600)' true
-
-
-
-  Covered decision/condition `desired_climb > (float)0' false
-
-
-
-  Covered decision/condition `climb_sum_err > (float)10' false
-
-
-
-  Covered decision/condition `climb_sum_err < (float)-10' false
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 393279 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered MC/DC independence condition `pprz >= (float)0 && !(pprz <= (float)(16 * 600))'
-
-
-
-  Covered condition `pprz >= (float)0' true
-
-
-
-  Covered decision/condition `pprz > (float)(16 * 600)' true
-
-
-
-  Covered condition `pprz <= (float)(16 * 600)' false
-
-
-
-  Covered decision/condition `desired_climb > (float)0' true
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 391285 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered MC/DC independence condition `pprz >= (float)0 && pprz <= (float)(16 * 600)'
-
-
-
-  Covered decision `pprz >= (float)0 && pprz <= (float)(16 * 600)' true
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 390122 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered decision/condition `climb_sum_err < (float)-10' true
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 390121 clauses
-
-
-
-  SAT checker: instance is SATISFIABLE
-
-
-
-  Covered decision/condition `climb_sum_err > (float)10' true
-
-
-
-  Solving with MiniSAT 2.2.1 with simplifier
-
-
-
-  131818 variables, 387493 clauses
-
-
-
-  SAT checker inconsistent: instance is UNSATISFIABLE
-
-
-
-  Runtime decision procedure: 3.806s
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-
-
-
-  
-  
-
-
-
-  
-    
-      -1.000000
-    
-    
-      1.000000
-    
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
-
-
-  
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-  
-  
-  
-  
-  
-  
-
-
-
-  
-    
-      0.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-  
-  
-  
-
-
-
-  
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      0.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-  
-  
-
-
-
-  
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-    
-      -1.000000
-    
-    
-      1.000000
-    
-  
-  
-
-
-
-  ** 18 of 19 covered (94.7%)
-
-
-
-  ** Used 7 iterations
-
-
-
diff --git a/doc/html-manual/properties.shtml b/doc/html-manual/properties.shtml
deleted file mode 100644
index af49380998..0000000000
--- a/doc/html-manual/properties.shtml
+++ /dev/null
@@ -1,208 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
Property Instrumentation

-
-
Properties

-
-

-We have mentioned properties several times so far, but we never
-explained what kind of properties CBMC
-and SATABS can verify.  We
-cover this topic in more detail in this section.

-
-

-Both CBMC and SATABS use 
-assertions to specify program properties. Assertions are properties of
-the state of the program when the program reaches a particular program
-location. Assertions are often written by the programmer by means of the
-assert macro.

-
-

-In addition to the assertions written by the programmer, assertions
-for specific properties can also be generated automatically
-by CBMC and SATABS, often relieving the programmer from writing
-"obvious" assertions.

-
-

-CBMC and SATABS come with an assertion generator called
-goto-instrument, which performs a conservative
-static analysis
-to determine program locations that potentially
-contain a bug. Due to the imprecision of the static
-analysis, it is important to emphasize that these
-generated assertions are only potential bugs, and
-that the Model Checker first needs to confirm that
-they are indeed genuine bugs.

-
-

-The assertion generator can generate assertions for
-the verification of the following properties:

-
-
    
-
  • 
-
    
-Buffer overflows.
-For each array access, check whether the upper and lower bounds
-are violated.
-
    • 
-
-
  • 
-Pointer safety. Search for NULL-pointer
-dereferences or dereferences of other invalid pointers.
-
    
-
    • 
-
-
  • 
-Division by zero.
-Check whether there is a division by zero in the program.
-
    
-
    • 
-
-
  • 
-Not-a-Number.
-Check whether floating-point computation may result in
-NaNs.
-
    
-
    • 
-
-
  • 
-Unitialized local.
-Check whether the program uses an uninitialized local variable.
-
    
-
    • 
-
-
  • 
-Data race.
-Check whether a concurrent program accesses a shared variable
-at the same time in two threads.
-
    
-
    • 
-
-

-
-
We refrain from explaining the properties above in
-detail.  Most of them relate to behaviors that are left undefined by the
-respective language semantics.  For a discussion on why these behaviors are
-usually very undesirable, read this blog post by John
-Regehr.

-
-

-All the properties described above are reachability properties.
-They are always of the form
-

-
-

-"Is there a path through the program such that property ...
-is violated?"
-

-
-

-The counterexamples to such properties are always
-program paths. Users of the Eclipse plugin can step through 
-these  counterexamples in a way that is similar to debugging programs.
-The installation of this plugin is explained 
-here.
-

-
-
Using goto-instrument

-
-

-The goto-instrument static analyzer operates on goto-binaries, which
-is a binary representation of control-flow graphs. The goto-binary
-is extracted from program source code using goto-cc, which
-is explained here.
-Given a goto-program, goto-instrument operates as follows:
-

-
-

-
    
-
  1. A goto-binary is read in.
    2. 
-
  2. The specified static analyses are performed.
    3. 
-
  3. Any potential bugs found are transformed into corresponding
-assertions, and are added into the program.
    4. 
-
  4. A new goto-binary (with assertions) is written to disc.
    5. 
-

-

-
-

-

-As an example, we begin with small C program we call
-expr.c
-(taken from here):
-

-
-

-
int *ptr;
-
-int main(void) {
-  if (ptr)
-    *ptr = 0;
-  if (!ptr)
-    *ptr = 1;
-}

-

-
-

-The program contains an obvious NULL-pointer dereference.
-We first compile the example program with goto-cc and
-then instrument the resulting goto-binary with
-pointer checks.
-

-
-

-
-  goto-cc expr.c -o in.gb

-  goto-instrument in.gb out.gb --pointer-check
-
-

-
-

-We can now get a list of the assertions that have been generated
-as follows:
-

-
-

-
-  goto-instrument out.gb --show-properties
-
-

-
-
Using either CBMC or SATABS on out.gb,
-we can obtain a counterexample trace for the NULL-pointer dereference:
-

-
-

-
-  cbmc out.gb
-
-

-

-
-
The goto-instrument program supports the following
-checks:
-

-
-
-
-
-
-
-
-
-
-
-
-
-
--no-assertions           ignore user assertions
--bounds-check            add array bounds checks
--div-by-zero-check       add division by zero checks
--pointer-check           add pointer checks
--signed-overflow-check   add arithmetic over- and underflow checks
--unsigned-overflow-check add arithmetic over- and underflow checks
--undefined-shift-check   add range checks for shift distances
--nan-check               add floating-point NaN checks
--uninitialized-check     add checks for uninitialized locals (experimental)
--error-label labelcheck that given label is unreachable

-
-

-
Further Reading

-
-

-
-
diff --git a/doc/html-manual/satabs-aeon.shtml b/doc/html-manual/satabs-aeon.shtml
deleted file mode 100644
index 3f078d406f..0000000000
--- a/doc/html-manual/satabs-aeon.shtml
+++ /dev/null
@@ -1,266 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
SATABS – Predicate Abstraction with SAT

-
-
Tutorials

-
-
Example: Buffer Overflow in a Mail Transfer Agent

-
-

-
-We explain how to model check Aeon version 0.2a, a small
-mail transfer agent written by Piotr Benetkiewicz. The description
-advertises Aeon as a "good choice for hardened or
-minimalistic boxes". The sources are available
-
-here.

-
-

-Our first naive attempt to verify Aeon using 
-

-
-

-satabs *.c
-

-
-

-produces a positive result, but also warns us that the property holds
-trivially.  It also reveals that a large number library functions are
-missing: SATABS is unable to find the source code for library functions like
-send, write and close.
-

-
-

-Now, do you have to provide a body for all missing library functions?
-There is no easy answer to this question, but a viable answer would
-be "most likely not". It is necessary to understand how SATABS 
-handles functions without bodies: It simply assumes that such a function
-returns an arbitrary value, but that no other
-locations than the one on the left hand side of the assignment are
-changed. Obviously, there are cases in which this assumption is
-un­sound, since the function potentially modifies all memory locations
-that it can somehow address.
-

-
-

-We now use static analysis to generate array bounds checks for
-Aeon:
-

-
-

-satabs *.c --pointer-check --bounds-check --show-properties
-

-
-

-SATABS will show about 300 properties in various functions
-(read this for more information
-on the property instrumentation).
-Now consider the first few lines of the main function 
-of Aeon:
-

-
-
int main(int argc, char **argv)
-{
-  char settings[MAX_SETTINGS][MAX_LEN];
-  ...
-  numSet = getConfig(settings);
-  if (numSet == -1) {
-    logEntry("Missing config file!");
-    exit(1);
-  }
-  ...
-

-
-

-and the function getConfig in lib_aeon.c:
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
int getConfig(char settings[MAX_SETTINGS][MAX_LEN])
{
  char home[MAX_LEN];
FILE *fp;                    /* .rc file handler */
int numSet = 0;              /* number of settings */
 
strcpy(home, getenv("HOME"));  /* get home path */
strcat(home, "/.aeonrc");    /* full path to rc file */
fp = fopen(home, "r");
if (fp == NULL) return -1;   /* no cfg - ERROR */

-
  while (fgets(settings[numSet], MAX_LEN-1, fp)
    && (numSet < MAX_SETTINGS)) numSet++;
fclose(fp);
 
return numSet;
}

-
-
-

-The function getConfig makes calls to 
-strcpy, strcat, getenv, fopen,
-fgets, and fclose. 
-It is very easy to provide an implementation for the functions from
-the string library (string.h), and SATABS comes with meaningful definitions
-for most of them.
-The definition of getenv is not so straight-forward.
-The man-page of getenv (which we obtain by entering
-man 3 getenv in a Unix or cygwin command prompt) tells us:
-

-
-

-
-`getenv'  searches  the  list  of en­vi­ron­ment 
-variable names and values
-(using the global pointer char **environ) 
-for a variable whose name
-matches  the  string  at NAME. If a variable name matches, 
-getenv returns a pointer to the associated value.
-
-

-
-

-SATABS has no information whatsoever about the content of
-environ. Even if SATABS could access the
-en­vi­ron­ment variables on your computer, a successful verification
-of Aeon would then only guarantee that the properties for
-this program hold on your computer with a specific set of
-en­vi­ron­ment variables. We have to assume that environ
-contains en­vi­ron­ment variables that have an arbitrary content
-of arbitrary length. The content of en­vi­ron­ment
-variables is not only arbitrary but could be malefic, since it
-can be modified by the user.  The approximation of the behavior of
-getenv that is shipped with SATABS completely ignores the
-content of the string.

-
-

-Now let us have another look at the properties that SATABS generates for the
-models of the the string library and for getenv.  Most of these
-properties require that we verify that the upper and lower bounds of buffers or
-arrays are not violated.  Let us look at one of the properties that SATABS
-generates for the code in function getConfig:
-

-
-

-
-Claim getConfig.3:

-  file lib_aeon.c line 19 function getConfig

-  dereference failure: NULL plus offset pointer

-  !(SAME-OBJECT(src, NULL))
-
-

-
-
The model of the function strcpy
-dereferences the pointer returned by getenv, which may
-return a NULL pointer. This possibility is detected by the static
-analysis, and thus a corresponding property is generated. Let us 
-check this specific property:
-

-
-

-satabs *.c --pointer-check --bounds-check --property getConfig.3
-

-
-
SATABS immediately returns a counterexample path
-that demonstrates how getenv returns a NULL, which
-is subsequently dereferenced. We have identified the first
-bug in this program: it requires that the environment variable
-HOME is set, and crashes otherwise.
-

-
-
Let us examine one more property in the
-same function:

-
-

-Claim getConfig.7:

-  file lib_aeon.c line 19 function getConfig

-  dereference failure: array `home' upper bound

-  !(POINTER_OFFSET(dst) + (int)i >= 512) || !(SAME-OBJECT(dst, &home[0]))

-

-
-

-This property asserts that the upper bound of the array home
-is not violated. The variable home
-looks familiar: We encountered it in the function getConfig
-given above. The function getenv in combination with functions
-strcpy, strcat or sprintf is indeed
-often the source for buffer overflows. Therefore, we try to use SATABS
-to check the upper bound of the array home:
-

-
-

-satabs *.c --pointer-check --bounds-check --property getConfig.7
-

-
-

-SATABS runs for quite a while and will eventually give up,
-telling us that its upper bound for abstraction refinement iterations
-has been exceeded. This is not exactly the result we were hoping for,
-and we could now increase the bound for iterations with help of the
---iterations command line switch of SATABS.
-

-
-

-Before we do this, let us investigate why SATABS has failed to provide
-a useful result. The function strcpy contains a loop
-that counts from 1 to the length of the input string. Predicate
-abstraction, the mechanism SATABS is based on, is unable to detect
-such loops and will therefore unroll the loop body as often as necessary.
-The array home has MAX_LEN elements, and 
-MAX_LEN is defined to be 512 in aeon.h. 
-Therefore, SATABS would have to run through at least 512 iterations, only to
-verify (or reject) one of the more than 300 properties! Does this fact
-defeat the purpose of static verification?
-

-
-

-We can make the job easier: after reducing the value of MAX_LEN
-in aeon.h to a small value, say to 10, SATABS provides a
-counterexample trace that demonstrates how the buffer overflow be
-reproduced.  If you use the Eclipse plugin (as described here), you can step through this
-counterexample. The trace contains the string that is returned
-by getenv.
-

-
-
-
-
-
diff --git a/doc/html-manual/satabs-background.shtml b/doc/html-manual/satabs-background.shtml
deleted file mode 100644
index b6d20fb08f..0000000000
--- a/doc/html-manual/satabs-background.shtml
+++ /dev/null
@@ -1,152 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
SATABS – Predicate Abstraction with SAT

-
-
Background

-
-
Sound Abstractions

-
-

-This section provides background information on how SATABS operates.  Even
-for very trivial C programs it is impossible to exhaustively examine their
-state space (which is potentially unbounded).  However, not all details in a
-C program necessarily contribute to a bug, so it may be sufficient to only
-examine those parts of the program that are somehow related to a bug.

-
-

-In practice, many static verification tools (such as lint) try to
-achieve this goal by applying heuristics.  This approach comes at a cost:
-bugs might be overlooked because the heuristics do not cover all relevant
-aspects of the program.  Therefore, the conclusion that a program is correct
-whenever such a static verification tool is unable to find an error is
-invalid.
-

-
-

-CEGAR Loop
-

-
-

-A more sophisticated approach that has been very successful recently
-is to generate a sound abstraction of the original program.
-In this context, soundness refers to the fact that the abstract program
-contains (at least) all relevant behaviors (i.e., bugs) that are present
-in the original program. In the Figure above, the first component 
-strips details from the original program. The number of possible behaviors
-increases as the number of details in the abstract program decreases.
-Intuitively, the reason is that whenever the model checking tool lacks the
-information that is necessary to make an accurate decision on whether a 
-branch of an control flow statement can be taken or not, both branches
-have to be considered.

-
-

-In the resulting abstract program, a set of concrete 
-states is subsumed by means of a single abstract state. Consider
-the following figure:
-

-
-

-
-

-
-

-The concrete states x1
-and x2 are mapped to an
-abstract state X, and similarly
-Y subsumes
-y1
-and y2.
-However, all transitions that are possible in the concrete program are also
-possible in the abstract model.  The abstract transition
-X → Y
-summarizes the concrete transitions
-x1 → y1
-and x1 →
-x1, and Y →
-X
-corresponds to x1 →
-x2.  The
-behavior 
-X → Y → 
-X is feasible in the original program,
-because it maps to
-x1 →
-x1 →
-x2.  However,
-Y →
-X →
-Y
-is feasible only in the abstract model.

-
-
Spurious Counterexamples

-
-

-The consequence is that the model checker (component number two in the
-figure above) possibly reports a spurious counterexample.  We call a
-counterexample spurious whenever it is feasible in the current abstract
-model but not in the original program.  However, whenever the model checker
-is unable to find an execution trace that violates the given property, we
-can conclude that there is no such trace in the original program, either.
-

-
-

-The feasibility of counterexamples is checked by symbolic simulation
-(performed by component three in the figure above).  If the counterexample
-is indeed feasible, SATABS found a bug in the original program and reports
-it to the user.
-

-
-
Automatic Refinement

-
-

-On the other hand, infeasible counterexamples
-(that originate from abstract behaviors that
-result from the omission of details and are not present in the original
-program) are never reported to the user.  Instead, the information is used
-in order to refine the abstraction such that the spurious counterexample is
-not part of the refined model anymore.  For instance, the reason for the
-infeasibility of Y
-→ X →
-Y is
-that neither
-y1 nor
-x1 can
-be reached from
-x2.
-Therefore, the abstraction can be refined by partitioning 
-X.
-

-
-

-The refinement steps can be illustrated as follows:
-

-
-

-Iterative refinement
-

-
-

-The first step (1) is to generate a very coarse abstraction with
-a very small state space. This abstraction is then successively
-refined (2, 3, ...) until either a feasible counterexample is found or the 
-abstract program is detailed enough to show that there is no
-path that leads to a violation of the given property. The problem
-is that this point is not necessarily reached for every input program,
-i.e., it is possible that the the abstraction refinement loop never
-terminates. Therefore, SATABS allows to specify an upper
-bound for the number of iterations.
-

-
-

-

-When this upper bound is reached and no counterexample was found,
-this does not necessarily mean that there is none. In this case, 
-you cannot make any conclusions at all with respect to the correctness 
-of the input program.
-

-

-
-
diff --git a/doc/html-manual/satabs-driver.shtml b/doc/html-manual/satabs-driver.shtml
deleted file mode 100644
index 2774b3fef6..0000000000
--- a/doc/html-manual/satabs-driver.shtml
+++ /dev/null
@@ -1,264 +0,0 @@
-
-
-
-
-
-
-
CPROVER Manual TOC

-
-
SATABS – Predicate Abstraction with SAT

-
-
Tutorials

-
-
Example: Reference Counting in Linux Device Drivers

-
-

-Microsoft's SLAM toolkit
-has been successfully used to find bugs in Windows device drivers.  SLAM
-automatically verifies device driver whether a device driver adheres to a
-set of specifications.  SLAM provides a test harness for device drivers that
-calls the device driver dispatch routines in a non-deterministic order. 
-Therefore, the Model Checker examines all combinations of calls.  Motivated
-by the success this approach, we provide a toy example based on Linux device
-drivers. For a more complete approach to the verification of Linux
-device drivers, consider DDVerify.
-

-
-

-Dynamically loadable modules enable the Linux Kernel to load device drivers
-on demand and to release them when they are not needed anymore.  When a
-device driver is registered, the kernel provides a major number that is used
-to uniquely identify the device driver.  The corresponding device can be
-accessed through special files in the filesystem; by convention, they are
-located in the /dev directory.  If a process accesses a device file
-the kernel calls the corresponding open, read and
-write functions of the device driver.  Since a driver must not be
-released by the kernel as long as it is used by at least one process, the
-device driver must maintain a usage counter (in more recent Linux kernels, this
-is done automatically, however, drivers that must maintain backward
-compatibility have to adjust this counter).
-

-
-

-We provide a skeleton of such a driver. Download the
-files
-spec.c,
-driver.c,
-driver.h,
-kdev_t.h, and
-modules.h.
-

-
-

-The driver contains following functions:

-
-
    
-
-  
  1.  register_chrdev:
-    (in spec.c) 
-    Registers a character device. In
-    our implementation, the function sets the variable usecount
-    to zero and returns a major number for this device (a constant, if
-    the user provides 0 as argument for the major number, and the value
-    specified by the user otherwise).
-  
    
-
-
    int usecount;
-
-int register_chrdev (unsigned int major, const char* name)
-{
-  usecount = 0;
-  if (major == 0)
-    return MAJOR_NUMBER;
-  return major;
-}
    
-
-
    2. 
-
-  
  2.  unregister_chrdev: (in spec.c)
-    Unregisters a character device.
-    This function asserts that the device is not used by any process
-    anymore (we use the macro MOD_IN_USE to check this).
-  
    
-
-
    int unregister_chrdev (unsigned int major, const char* name)
-{
-  if (MOD_IN_USE)
-    {
-    ERROR: assert (0);
-    }
-  else
-    return 0;
-}
    
-
    3. 
-
-  
  3.  dummy_open: (in
-    driver.c) This function
-    increases the usecount. If the device is locked by
-    some other process dummy_open returns -1. Otherwise
-    it locks the device for the caller.     
-  
    
-
    4. 
-
-
  4.  dummy_read: (in driver.c) This function
-    "simulates" a read access to the device. In fact it does 
-    nothing, since we are currently not interested in the potential buffer
-    overflow that may result from a call to this function.
-    Note the usage of
-    the function nondet_int: 
-    This is an internal SATABS-function that non­determi­nistically
-    returns an arbitrary integer
-    value. The function __CPROVER_assume
-    tells SATABS to ignore
-    all traces that do not adhere to the given assumption. Therefore,
-    whenever the lock is held, dummy_read will 
-    return a value between 0 and  max. If the lock is not held,
-    then dummy_read returns -1.
-  
    
-
    5. 
-
-
  5.  dummy_release: (in driver.c) If the lock
-is held, then dummy_release decreases
-the usecount, releases the lock, and returns 0. Otherwise,
-the function returns -1.
-
    6. 
-
-

-
-

-We now want to check if any valid sequence of calls of the 
-dispatch functions (in driver.c) can lead to the violation 
-of the assertion (in spec.c).
-Obviously, a call to dummy_open that is immediately followed
-by a call to unregister_chrdev violates the assertion.
-

-
-

-The function main in spec.c gives an example of
-how these functions are called. First, a character device
-"dummy" is registered. The major number is stored
-in the inode structure of the device. The values
-for the file structure are assigned non-deterministically.
-We rule out invalid sequences of calls by ensuring
-that no device is unregistered while it is still locked.
-We use the following model checking harness for calling the
-dispatching functions:
-

-
-
      random = nondet_uchar ();
-      __CPROVER_assume (0 <= random && random <= 3);
-
-      switch (random)
-      {
-      case 1: 
-        rval = dummy_open (&inode, &my_file);
-        if (rval == 0)
-          lock_held = TRUE;
-        break;
-      case 2:
-        __CPROVER_assume (lock_held);
-        count = dummy_read (&my_file, buffer, BUF_SIZE); 
-        break;
-      case 3:
-        dummy_release (&inode, &my_file);
-        lock_held = FALSE;
-        break;
-      default:
-        break;
-      }
-

-
-

-The variable random is assigned non-deterministically.
-Subsequently, the value of random
-is restricted to be 0 &le random ≤ 3 by a call to
-__CPROVER_assume. Whenever the value of random is
-not in this interval, the corresponding execution trace is simply 
-discarded by SATABS. Depending on the value of random, the
-harness calls either dummy_open, dummy_read or
-dummy_close. Therefore, 
-if there is a sequence of calls to these three
-functions that leads to a violation of the assertion in 
-unregister_chrdev, then SATABS
-will eventually consider it.
-

-
-

-If we ask SATABS to show us the properties it verifies with
-

-
-

-satabs driver.c spec.c --show-properties
-

-
-

-for our example, we obtain 
-

-
-
    
-
-
  1. 
-Claim unregister_chrdev.1:
    
-    file spec.c line 18 function unregister_chrdev
    
-    MOD_IN_USE in unregister_chrdev
    
-    FALSE
-
    
-
    2. 
-
-
  2. 
-Claim dummy_open.1:
    
-    file driver.c line 15 function dummy_open
    
-    i_rdev mismatch
    
-    (unsigned int)inode->i_rdev >> 8 == (unsigned int)dummy_major
-
    
-
    3. 
-
-

-
-

-It seems obvious that the property dummy_open.1
-can never be violated. SATABS confirms
-this assumption: We call
-

-
-

-satabs driver.c spec.c --property dummy_open.1
-

-
-

-and SATABS reports VERIFICATION SUCCESSFUL after a few iterations.
-

-
-
 If we try to verify property unregister_chrdev.1, SATABS
-reports that the property in line 18 in file spec.c is violated (i.e., the
-assertion does not hold, therefore the VERIFICATION FAILED). 
-Furthermore, SATABS provides a detailed description of the problem in the
-form of a counterexample (i.e., an execution trace that violates the
-property).  On this trace, dummy_open is called twice,
-leading to a usecount of 2. The second call of course fails
-with rval=-1, but the counter is increased nevertheless:
-

-
-
int dummy_open (struct inode *inode, struct file *filp)
-{
-  __CPROVER_assert(MAJOR (inode->i_rdev) == dummy_major,
-      "i_rdev mismatch");
-  MOD_INC_USE_COUNT;
-
-  if (locked)
-    return -1;
-  locked = TRUE;
-
-  return 0; /* success */
-}
-

-
-

-Then, dummy_release is called to release the lock on the
-device.  Finally, the loop is left and the call to
-unregister_chrdev results in a violation of the assertion
-(since usecount is still 1, even though locked=0). 
-

-
-
-
diff --git a/doc/html-manual/satabs-tutorials.shtml b/doc/html-manual/satabs-tutorials.shtml
deleted file mode 100644
index f842f6a30c..0000000000
--- a/doc/html-manual/satabs-tutorials.shtml
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
CPROVER Manual TOC

-
-
SATABS – Predicate Abstraction with SAT

-
-
Tutorials

-
-

-We provide an introduction to model checking "real"
-C programs with SATABS using two small examples:
-

-
-
    
-
-
  • An example based on Linux device drivers.
-
    • 
-
-
  • An example based on a Mail Transfer Agent.
-
    • 
-
-
    
-
-
-
diff --git a/doc/html-manual/satabs.shtml b/doc/html-manual/satabs.shtml
deleted file mode 100644
index 8418012047..0000000000
--- a/doc/html-manual/satabs.shtml
+++ /dev/null
@@ -1,178 +0,0 @@
-
-
-
-
-
-
-
    CPROVER Manual TOC
    
-
-
    SATABS – Predicate Abstraction with SAT
    
-
-
    Overview
    
-
-
    
-This section describes SATABS from the point of view of the user. To learn
-about the technology implemented in SATABS, read this
-section.
-
    
-
-
    
-We assume you have already installed SATABS and the necessary support files
-on your system. If not so, please follow 
-these instructions.
-
    
-
-
    
-While users of SATABS
-almost never have to be concerned about the underlying refinement
-abstraction algorithms, understanding the classes of properties that 
-can be verified is crucial. Predicate abstraction is most effective
-when applied to control-flow dominated properties. As
-an example, reconsider the following program
-(lock-example-fixed.c):
-
    
-
-
    _Bool nondet_bool();
-_Bool LOCK = 0;
-
-_Bool lock() {
-  if(nondet_bool()) {
-    assert(!LOCK);
-    LOCK=1;
-    return 1; }
-
-  return 0;
-}
-
-void unlock() {
-  assert(LOCK);
-  LOCK=0;
-}
-
-int main() {
-  unsigned got_lock = 0;
-  int times;
-
-  while(times > 0) {
-    if(lock()) {
-      got_lock++;
-      /* critical section */
-    }
-
-    if(got_lock!=0) {
-      unlock();
-      got_lock--;
-    }
-
-    times--;
-} }
-
    
-
-
    
-The two assertions in the program model that the functions lock()
-and unlock() are called in the right order. Note that the value
-of times is chosen non-deterministically and is not bounded. The program has
-no run-time bound, and thus, unwinding the code with 
-CBMC will never terminate.
    
-
-
    Working with Claims
    
-
-
    
-The two assertions will give rise to two properties.
-Each property is associated to a specific line of code, i.e., a property is violated when
-some condition can become false at the corresponding program location.
-SATABS will generate a list of all properties for the programs as follows:
-
    
-
-
    
-
-satabs lock-example-fixed.c --show-properties
-
-
    
-
-
    SATABS will list two properties; each property corresponds to one of the
-two assertions. We can use SATABS to verify both properties
-as follows:
-
    
-
-
    
-
-satabs lock-example-fixed.c
-
-
    
-
-
    
-SATABS will conclude the verification successfully, that is, both
-assertions hold for execution traces of any length.
-
    
-
-
    
-By default, SATABS attempts to verify all properties at once.
-A single property can be verified (or refuted) by using the
---property id option of SATABS,
-where id denotes the identifier of the property in the list
-obtained by calling SATABS with the --show-properties flag. Whenever
-a property is violated, SATABS reports a feasible path that leads to a state
-in which the condition that corresponds to the violated property evaluates to
-false.
-
    
-
-
    Programs that use Libraries
    
-
-
    
-SATABS cannot check programs that use functions that are
-only available in binary (compiled) form (this restriction
-is not imposed by the verification algorithms that are used by SATABS –
-they also work on assembly code). The reason is simply that so far
-no assembly language frontend is available for SATABS. At the moment,
-(library) functions for which no C source code is available have to be
-replaced by stubs. The usage of stubs and harnesses (as known from unit 
-testing) also allows to check more complicated properties (like, for 
-example, whether function fopen is always called before
-fclose). This technique is explained in detail 
-in the SATABS tutorials.
-
    
-
-
    Unit Testing with SATABS
    
-
-
    
-The example presented here is obviously a
-toy example and can hardly be used to convince your project manager to use
-static verification in your next project.  Even though we recommend to use
-formal verification and specification already in the early phases of your
-project, the sad truth is that in most projects verification (of any kind)
-is still pushed to the very end of the development cycle.  Therefore, this
-section is dedicated to the verification of legacy code.  However, the
-techniques presented here can also be used for unit testing.
-
    
-
-
    
-Unit testing is used in most software development projects, and static
-verification with SATABS can be very well combined with this technique. 
-Unit testing relies on a number test cases that yield the desired code
-coverage.  Such test cases are implemented by a software testing engineer in
-terms of a test harness (aka test driver) and a set of function stubs. 
-Typically, a slight modification to the test harness allows it to be used
-with SATABS.  Replacing the explicit input values with non-deterministic
-inputs (as explained in here and
-here) guarantees that SATABS will try to
-achieve full path and state coverage (due to the fact that
-predicate abstraction implicitly detects equivalence classes).
-However, it is not guaranteed that SATABS terminates in all cases.
-Keep in mind that you must not make any assumptions about the
-validity of the properties if SATABS did not run to completion!
-
    
-
-
    
-
    Further Reading
    
-
-
    
-
-
diff --git a/src/doxyfile b/src/doxyfile
index 7d894c4e70..1929468b70 100644
--- a/src/doxyfile
+++ b/src/doxyfile
@@ -771,7 +771,7 @@ WARN_LOGFILE           =
 # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
 # Note: If this tag is empty the current directory is searched.
 
-INPUT                  = .
+INPUT                  = . ../doc
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
@@ -797,7 +797,8 @@ INPUT_ENCODING         = UTF-8
 # *.vhd, *.vhdl, *.ucf, *.qsf, *.as and *.js.
 
 FILE_PATTERNS          = *.cpp \
-                         *.h
+                         *.h    \
+                         *.md
 
 # The RECURSIVE tag can be used to specify whether or not subdirectories should
 # be searched for input files as well.
@@ -846,7 +847,7 @@ EXCLUDE_SYMBOLS        =
 # that contain example code fragments that are included (see the \include
 # command).
 
-EXAMPLE_PATH           = 
+EXAMPLE_PATH           = ../doc/assets
 
 # If the value of the EXAMPLE_PATH tag contains directories, you can use the
 # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
@@ -866,7 +867,7 @@ EXAMPLE_RECURSIVE      = NO
 # that contain images that are to be included in the documentation (see the
 # \image command).
 
-IMAGE_PATH             = 
+IMAGE_PATH             = ../doc/assets
 
 # The INPUT_FILTER tag can be used to specify a program that doxygen should
 # invoke to filter for each input file. Doxygen will invoke the filter program
@@ -922,7 +923,7 @@ FILTER_SOURCE_PATTERNS =
 # (index.html). This can be useful if you have a project on for instance GitHub
 # and want to reuse the introduction page also for the doxygen output.
 
-USE_MDFILE_AS_MAINPAGE = 
+USE_MDFILE_AS_MAINPAGE = ../doc/architectural/front-page.md
 
 #---------------------------------------------------------------------------
 # Configuration options related to source browsing