pax_global_header00006660000000000000000000000064130140651370014512gustar00rootroot0000000000000052 comment=8a0088ecfacd4b88ed9a606da415bff1211ee114 cbmc-cbmc-5.6/000077500000000000000000000000001301406513700131725ustar00rootroot00000000000000cbmc-cbmc-5.6/.gitattributes000066400000000000000000000001751301406513700160700ustar00rootroot00000000000000*.cpp text *.c text *.h text *.y text *.tex text *.shtml text *.html text *.css text *.inc text test.desc text Makefile text cbmc-cbmc-5.6/.gitignore000066400000000000000000000035701301406513700151670ustar00rootroot00000000000000# compilation files *.lo *.od *.d *.o *.obj *.a *.lib src/ansi-c/arm_builtin_headers.inc src/ansi-c/clang_builtin_headers.inc src/ansi-c/cprover_library.inc src/ansi-c/cw_builtin_headers.inc src/ansi-c/gcc_builtin_headers_alpha.inc src/ansi-c/gcc_builtin_headers_arm.inc src/ansi-c/gcc_builtin_headers_generic.inc src/ansi-c/gcc_builtin_headers_ia32-2.inc src/ansi-c/gcc_builtin_headers_ia32.inc src/ansi-c/gcc_builtin_headers_mips.inc src/ansi-c/gcc_builtin_headers_power.inc src/util/irep_ids.h src/util/irep_ids.inc # regression/test files *.out regression/ansi-c/tests.log regression/symex/tests.log regression/cbmc-java/tests.log regression/cbmc/tests.log src/big-int/test-bigint src/big-int/test-bigint.exe # files stored by editors *~ # libs downloaded by make [name]-download libzip/ zlib/ minisat*/ glucose-syrup/ # flex/bison generated files src/ansi-c/ansi_c_lex.yy.cpp src/ansi-c/ansi_c_y.output src/ansi-c/ansi_c_y.tab.cpp src/ansi-c/ansi_c_y.tab.h src/assembler/assembler_lex.yy.cpp src/jsil/jsil_lex.yy.cpp src/jsil/jsil_y.output src/jsil/jsil_y.tab.cpp src/jsil/jsil_y.tab.h src/json/json_lex.yy.cpp src/json/json_y.output src/json/json_y.tab.cpp src/json/json_y.tab.h src/xmllang/xml_lex.yy.cpp src/xmllang/xml_y.output src/xmllang/xml_y.tab.cpp src/xmllang/xml_y.tab.h # binaries src/cbmc/cbmc src/cbmc/cbmc.exe src/cegis/cegis src/cegis/cegis.exe src/goto-analyzer/goto-analyzer src/goto-analyzer/goto-analyzer.exe src/goto-cc/goto-cc src/goto-cc/goto-cc.exe src/goto-cc/goto-cl.exe src/goto-instrument/goto-instrument src/goto-instrument/goto-instrument.exe src/musketeer/musketeer src/musketeer/musketeer.exe src/symex/symex src/symex/symex.exe src/goto-diff/goto-diff src/goto-diff/goto-diff.exe # build tools src/ansi-c/file_converter src/ansi-c/file_converter.exe src/ansi-c/library/converter src/ansi-c/library/converter.exe src/util/irep_ids_convert src/util/irep_ids_convert.exe cbmc-cbmc-5.6/.travis.yml000066400000000000000000000013271301406513700153060ustar00rootroot00000000000000language: cpp os: - linux - osx sudo: required addons: apt: packages: - libwww-perl compiler: - gcc - clang before_install: - if [ "$(expr substr $(uname -s) 1 5)" == "Linux" ] ; then sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test && sudo apt-get -qq update && sudo apt-get -qq install g++-4.8 gcc-4.8 && sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 90 && sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 90 ; fi install: - chmod a+x regression/failed-tests-printer.pl - cd src && make minisat2-download script: - make CXXFLAGS="-Wall -O2 -g -Werror -Wno-deprecated-register -pedantic -Wno-sign-compare" -j2 && cd ../regression && make test cbmc-cbmc-5.6/CHANGELOG000066400000000000000000000044401301406513700144060ustar00rootroot000000000000004.7 === Added support for Solaris 11. Bugfixes in partial-order encoding. Added --float-overflow-check 4.6 === Improved floating-point encoding. Improved AIG->CNF encoder. 4.5 === Optimizations to reduce memory consumption. Bugfixes in partial-order encoding. 4.4 === Now checks concurrent programs, with partial-order encoding. Support for SMT-LIB standard floating-point theory. goto-instrument knows k-induction and underapproximating loop accelleration. 4.3 === Floating-point arithmetic now takes the rounding mode into account, which can be changed dynamically. goto-gcc generates hybrid executables on Linux, containing both machine code and the CFG. Limited support for Spec#-style quantifiers added. Pointer-checks no longer use a heavy-weight alias analysis. Limited support for some x86 and ARM inline assembly constructs. 4.2 === goto-cc now passes all command line options to the gcc preprocessor. The MacOS binaries are now signed. The C/C++ front-end has been tested and fixed for the Visual Studio 2012 header files. The man-page has been elaborated. Support for the C99 complex type and gcc's vector type has been added. Various built-ins for x86 MMX and SSE instructions have been added. Support for various C11 features has been added. Support for various built-in primitives has been added, in particular for the __sync_* commands. New feature: --all-claims now reports the status of all claims; the verification continues even if a counterexample is found. This feature uses incremental SAT. The counterexample beautification (--beautify) now uses incremental SAT. Numerous improvements to SMT1 and SMT2 interfaces. Support for further SAT solvers (PRECOSAT, PICOSAT, LINGELING) 4.1 === The support for low-level accesses to dynamically allocated data structures and "integer addressed memory" (usually memory-mapped I/O) has been further improved. Numerous improvements to the SMT back-ends. Specifically, support through the SMT1 path for Boolector and Z3 has been improved; support for MathSAT has been added. In combination with the very latest version of MathSAT, CBMC now also supports an SMT2 flow (use --mathsat --smt2 to activate this). 4.0 === Better support for low-level accesses to dynamically allocated data structures. Numerous front-end improvements. cbmc-cbmc-5.6/CODING_STANDARD000066400000000000000000000011721301406513700153410ustar00rootroot00000000000000Here a few minimalistic coding rules for the cprover source tree: a) 2 spaces indent, no tabs b) no "using namespace std;" c) Avoid new/delete, use containers instead. d) Avoid unnecessary #includes, especially in header files e) No lines wider than 80 chars f) Put matching { } into the same column g) If a method is bigger than a page, break it into parts h) Avoid destructive updates if possible. The irept has constant time copy. Architecture-specific code: a) Avoid if possible. b) Use __LINUX__, __MACH__, and _WIN32 to distinguish the architectures. c) Don't include architecture-specific header files without #ifdef ... cbmc-cbmc-5.6/COMPILING000066400000000000000000000116501301406513700144410ustar00rootroot00000000000000What architecture? ------------------ CPROVER now needs a C++11 compliant compiler and works in the following environments: - Linux - MacOS X - Solaris 11 - FreeBSD 10 or 11 - Cygwin (We recommend the i686-pc-mingw32-g++ cross compiler, version 4.7 or above.) - Microsoft's Visual Studio version 12 (2013), version 14 (2015), or version 15 (older versions won't work) The rest of this document is split up into three parts: compilation on Linux, MacOS, Windows. Please read the section appropriate for your machine. COMPILATION ON LINUX -------------------- We assume that you have a Debian/Ubuntu or Red Hat-like distribution. 0) You need a C/C++ compiler, Flex and Bison, and GNU make. The GNU Make needs to be version 3.81 or higher. On Debian-like distributions, do apt-get install g++ gcc flex bison make git libz-dev libwww-perl patch libzip-dev On Red Hat/Fedora or derivates, do yum install gcc gcc-c++ flex bison perl-libwww-perl patch 1) As a user, get the CBMC source via git clone https://github.com/diffblue/cbmc cbmc-git 2) Do cd cbmc-git/src make minisat2-download make libzip-download zlib-download make libzip-build make COMPILATION ON SOLARIS 11 ------------------------- 1) As root, get the necessary development tools: pkg install system/header developer/lexer/flex developer/parser/bison developer/versioning/git pkg install --accept developer/gcc-49 2) As a user, get the CBMC source via git clone https://github.com/diffblue/cbmc cbmc-git 3) Get MiniSat2 by entering cd cbmc-git wget http://ftp.debian.org/debian/pool/main/m/minisat2/minisat2_2.2.1.orig.tar.gz gtar xfz minisat_2.2.1.orig.tar.gz mv minisat2-2.2.1 minisat-2.2.1 (cd minisat-2.2.1; patch -p1 < ../scripts/minisat-2.2.1-patch) 4) Type cd src; gmake That should do it. To run, you will need export LD_LIBRARY_PATH=/usr/gcc/4.9/lib Do not attempt to compile with gcc-45 that comes with Solaris 11. It will mis-optimize MiniSat2. COMPILATION ON FREEBSD 10/11 ---------------------------- 1) As root, get the necessary tools: pkg install bash gmake git www/p5-libwww patch flex bison 2) As a user, get the CBMC source via git clone https://github.com/diffblue/cbmc cbmc-git 3) Do cd cbmc-git/src 4) Do gmake minisat2-download gmake COMPILATION ON MACOS X ---------------------- Follow these instructions: 0) You need a C/C++ compiler, Flex and Bison, and GNU make. To this end, first install the XCode from the App-store and then type xcode-select --install in a terminal window. 1) Then get the CBMC source via git clone https://github.com/diffblue/cbmc cbmc-git 2) Then type cd cbmc-git/src make minisat2-download make libzip-download zlib-download make libzip-build make COMPILATION ON WINDOWS ---------------------- There are two options: compilation using g++ from Cygwin, or using Visual Studio's compiler. As Cygwin has significant overhead during process creation, we advise you use Visual Studio. Follow these instructions: 0) You need a C/C++ compiler, Flex and Bison, GNU tar, gzip2, GNU make, and patch. The GNU Make needs to be version 3.81 or higher. If you don't already have the above, we recommend you install Cygwin. 1) You need a SAT solver (in source). We recommend MiniSat2. Using a browser, download from http://ftp.debian.org/debian/pool/main/m/minisat2/minisat2_2.2.1.orig.tar.gz and then unpack with tar xfz minisat-2.2.1.tar.gz mv minisat minisat-2.2.1 cd minisat-2.2.1 patch -p1 < ../scripts/minisat-2.2.1-patch The patch removes the dependency on zlib and prevents a problem with a header file that is often unavailable on Windows. 2) Adjust src/config.inc for the paths to item 1). 3A) To compile with Cygwin, install the mingw compilers, and adjust the second line of config.inc to say BUILD_ENV = MinGW 3B) To compile with Visual Studio, make sure you have at least Visual Studio version 12 (2013), and adjust the second line of config.inc to say BUILD_ENV = MSVC Open the Visual Studio Command prompt, and then run the make.exe from Cygwin from in there. 4) Type cd src; make - that should do it. Note that "nmake" is not expected to work. Use "make". (Optional) A Visual Studio project file can be generated with the script "generate_vcxproj" that is in the subdirectory "scripts". The project file is helpful for GUI-based tasks, e.g., the class viewer, debugging, etc., and can be used for building with MSBuild. Note that you still need to run flex/bison using "make generated_files" before opening the project. WORKING WITH ECLIPSE -------------------- To work with Eclipse, do the following: 1) Select File -> New -> Makefile Project with Existing Code 2) Type "cprover" as "Project Name" 3) Select the "src" subdirectory as "Existing Code Location" 4) Select a toolchain appropriate for your platform 5) Click "Finish" 6) Select Project -> Build All cbmc-cbmc-5.6/LICENSE000066400000000000000000000036501301406513700142030ustar00rootroot00000000000000(C) 2001-2016, Daniel Kroening, Edmund Clarke, Computer Science Department, University of Oxford Computer Science Department, Carnegie Mellon University All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. 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. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Daniel Kroening, Edmund Clarke, Computer Science Department, University of Oxford Computer Science Department, Carnegie Mellon University 4. Neither the name of the University 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 COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER OR 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. cbmc-cbmc-5.6/README.md000066400000000000000000000015351301406513700144550ustar00rootroot00000000000000[![Build Status][build_img]][travis] [CProver Wiki](http://www.cprover.org/wiki) About ===== CBMC is a Bounded Model Checker for C and C++ programs. It supports C89, C99, most of C11 and most compiler extensions provided by gcc and Visual Studio. It also supports SystemC using Scoot. It allows verifying array bounds (buffer overflows), pointer safety, exceptions and user-specified assertions. Furthermore, it can check C and C++ for consistency with other languages, such as Verilog. The verification is performed by unwinding the loops in the program and passing the resulting equation to a decision procedure. For full information see [cprover.org](http://www.cprover.org/cbmc). License ======= 4-clause BSD license, see `LICENSE` file. [build_img]: https://travis-ci.org/diffblue/cbmc.svg?branch=master [travis]: https://travis-ci.org/diffblue/cbmc cbmc-cbmc-5.6/doc/000077500000000000000000000000001301406513700137375ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/guide/000077500000000000000000000000001301406513700150345ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/guide/CBMC-guide.tex000066400000000000000000000736171301406513700173730ustar00rootroot00000000000000\documentclass{article} \newcommand{\dir}[1]{\texttt{#1}} \newcommand{\file}[1]{\texttt{#1}} \newcommand{\code}[1]{\texttt{#1}} \newcommand{\prog}[1]{\texttt{#1}} \title{Beginner's Guide to CPROVER} \author{Martin Brain\thanks{But most of the content is from Michael Tautschnig}} \begin{document} \maketitle \section{Background Information} First off; read the CPROVER manual. It describes how to get, build and use CBMC and SATABS. This document covers the internals of the system and how to get started on development. \subsection{Documentation} Apart from the (user-orientated) CPROVER manual and this document, most of the rest of the documentation is inline in the code as \texttt{doxygen} and some comments. A man page for CBMC, goto-cc and goto-instrument is contained in the \dir{doc/} directory and gives some options for these tools. All of these could be improved and patches are very welcome. In some cases the algorithms used are described in the relevant papers. \subsection{Architecture} CPROVER is structured in a similar fashion to a compiler. It has language specific front-ends which perform limited syntactic analysis and then convert to an intermediate format. The intermediate format can be output to files (this is what \texttt{goto-cc} does) and are (informally) referred to as ``goto binaries'' or ``goto programs''. The back-end are tools process this format, either directly from the front-end or from it's saved output. These include a wide range of analysis and transformation tools (see Section \ref{section:other-apps}). \subsection{Coding Standards} CPROVER is written in a fairly minimalist subset of C++; templates and meta-programming are avoided except where necessary. The standard library is used but in many cases there are alternatives provided in \dir{util/} (see Section \ref{section:util}) which are preferred. Boost is not used. Patches should be formatted so that code is indented with two space characters, not tab and wrapped to 75 or 72 columns. Headers for doxygen should be given (and preferably filled!) and the author will be the person who first created the file. Identifiers should be lower case with underscores to separate words. Types (classes, structures and typedefs) names must\footnote{There are a couple of exceptions, including the graph classes} end with a \code{t}. Types that model types (i.e. C types in the program that is being interpreted) are named with \code{\_typet}. For example \code{ui\_message\_handlert} rather than \code{UI\_message\_handlert} or \code{UIMessageHandler} and \code{union\_typet}. \subsection{How to Contribute} Fixes, changes and enhancements to the CPROVER code base should be developed against the \texttt{trunk} version and submitted to Daniel as patches produced by \texttt{diff -Naur} or \texttt{svn diff}. Entire applications are best developed independently (\texttt{git svn} is a popular choice for tracking the main trunk but also having local development) until it is clear what their utility, future and maintenance is likely to be. \subsection{Other Useful Code} \label{section:other-apps} The CPROVER subversion archive contains a number of separate programs. Others are developed separately as patches or separate branches.% New applications are initially developed in their version %control system and may be merged into the main subversion system %depending on their utility, popularity and maintenance. Interfaces are have been and are continuing to stablise but older code may require work to compile and function correctly. In the main archive: \begin{description} \item[\prog{CBMC}]{A bounded model checking tool for C and C++. See Section \ref{section:CBMC}.} \item[\prog{goto-cc}]{A drop-in, flag compatible replacement for GCC and other compilers that produces goto-programs rather than executable binaries. See Section \ref{section:goto-cc}.} \item[\prog{goto-instrument}]{A collection of functions for instrumenting and modifying goto-programs. See Section \ref{section:goto-instrument}.} \end{description} Model checkers and similar tools: \begin{description} \item[\prog{SatABS}]{A CEGAR model checker using predicate abstraction. Is roughly 10,000 lines of code (on top of the CPROVER code base) and is developed in its own subversion archive. It uses an external model checker to find potentially feasible paths. Key limitations are related to code with pointers and there is scope for significant improvement.} \item[\prog{Scratch}]{Alistair Donaldson's k-induction based tool. The front-end is in the old project CVS and some of the functionality is in \prog{goto-instrument}.} \item[\prog{Wolverine}]{An implementation of Ken McMillan's IMPACT algorithm for sequential programs. In the old project CVS.} \item[\prog{C-Impact}]{An implementation of Ken McMillan's IMPACT algorithm for parallel programs. In the old project CVS.} \item[\prog{LoopFrog}]{A loop summarisation tool.} \item[\prog{???}]{Christoph's termination analyser.} \end{description} Test case generation: \begin{description} \item[\prog{cover}]{A basic test-input generation tool. In the old project CVS.} \item[\prog{FShell}]{A test-input generation tool that allows the user to specify the desired coverage using a custom language (which includes regular expressions over paths). It uses incremental SAT and is thus faster than the na\"ive ``add assertions one at a time and use the counter-examples'' approach. Is developed in its own subversion.} \end{description} Alternative front-ends and input translators: \begin{description} \item[\prog{Scoot}]{A System-C to C translator. Probably in the old project CVS.} \item[\prog{???}]{A Simulink to C translator. In the old project CVS.} \item[\prog{???}]{A Verilog front-end. In the old project CVS.} \item[\prog{???}]{A converter from Codewarrior project files to Makefiles. In the old project CVS.} \end{description} Other tools: \begin{description} \item[\prog{ai}]{Leo's hybrid abstract interpretation / CEGAR tool.} \item[\prog{DeltaCheck?}]{Ajitha's slicing tool, aimed at locating changes and differential verification. In the old project CVS.} \end{description} There are tools based on the CPROVER framework from other research groups which are not listed here. \section{Source Walkthrough} This section walks through the code bases in a rough order of interest / comprehensibility to the new developer. \subsection{\dir{doc}} At the moment just contains the CBMC man page. \subsection{\dir{regression/}} The regression tests are currently being moved from CVS. The \dir{regression/} directory contains all of those that have been moved. They are grouped into directories for each of the tools. Each of these contains a directory per test case, containing a C or C++ file that triggers the bug and a \file{.dsc} file that describes the tests, expected output and so on. There is a Perl script, \file{test.pl} that is used to invoke the tests as: \begin{center} \code{../test.pl -c PATH\_TO\_CBMC} \end{center} The \code{--help} option gives instructions for use and the format of the description files. \subsection{\dir{src/}} The source code is divided into a number of sub-directories, each containing the code for a different part of the system. In the top level files there are only a few files: \begin{description} \item[\file{config.inc}]{The user-editable configuration parameters for the build process. The main use of this file is setting the paths for the various external SAT solvers that are used. As such, anyone building from source will likely need to edit this.} \item[\file{Makefile}]{The main systems Make file. Parallel builds are supported and encouraged; please don't break them!} \item[\file{common}]{System specific magic required to get the system to build. This should only need to be edited if porting CBMC to a new platform / build environment.} \item[\file{doxygen.cfg}]{The config file for doxygen.cfg} \end{description} \subsubsection{\dir{util/}} \label{section:util} \dir{util/} contains the low-level data structures and manipulation functions that are used through-out the CPROVER code-base. For almost any low-level task, the code required is probably in \dir{util/}. Key files include: \begin{description} \item[\file{irep.h}]{This contains the definition of \code{irept}, the basis of many of the data structures in the project. They should not be used directly; one of the derived classes should be used. For more information see Section \ref{section:irept}.} \item[\file{expr.h}]{The parent class for all of the expressions. Provides a number of generic functions, \code{exprt} can be used with these but when creating data, subclasses of \code{exprt} should be used.} \item[\file{std\_expr.h}]{Provides subclasses of \code{exprt} for common kinds of expression for example \code{plus\_exprt}, \code{minus\_exprt}, \code{dereference\_exprt}. These are the intended interface for creating expressions.} \item[\file{std\_types.h}]{Provides subclasses of \code{typet} (a subclass of \code{irept}) to model C and C++ types. This is one of the preferred interfaces to \code{irept}. The front-ends handle type promotion and most coercision so the type system and checking goto-programs is simpler than C.} \item[\file{dstring.h}]{The CPROVER string class. This enables sharing between strings which significantly reduces the amount of memory required and speeds comparison. \code{dstring} should not be used directly, \code{irep\_idt} should be used instead, which (dependent on build options) is an alias for \code{dstring}.} \item[\file{mp\_arith.h}]{The wrapper class for multi-precision arithmetic within CPROVER. Also see \file{arith\_tools.h}.} \item[\file{ieee\_float.h}]{The arbitrary precision float model used within CPROVER. Based on \code{mp\_integer}s.} \item[\file{context.h}]{A generic container for symbol table like constructs such as namespaces. Lookup gives type, location of declaration, name, `pretty name', whether it is static or not.} \item[\file{namespace.h}]{The preferred interface for the context class. The key function is \code{lookup} which converts a string (\code{irep\_idt}) to a symbol which gives the scope of declaration, type and so on. This works for functions as well as variables.} \end{description} \subsubsection{\dir{langapi/}} This contains the basic interfaces and support classes for programming language front ends. Developers only really need look at this if they are adding support for a new language. It's main users are the two (in trunk) language front-ends; \dir{ansi-c/} and \dir{cpp/}. \subsubsection{\dir{ansi-c/}} Contains the front-end for ANSI C, plus a variety of common extensions. This parses the file, performs some basic sanity checks (this is one area in which the UI could be improved; patches most welcome) and then produces a goto-program (see below). The parser is a traditional Flex / Bison system. \file{internal\_addition.c} contains the implementation of various `magic' functions that are that allow control of the analysis from the source code level. These include assertions, assumptions, atomic blocks, memory fences and rounding modes. The \dir{library/} subdirectory contains versions of some of the C standard header files that make use of the CPROVER built-in functions. This allows CPROVER programs to be `aware' of the functionality and model it correctly. Examples include \file{stdio.c}, \file{string.c}, \file{setjmp.c} and various threading interfaces. \subsubsection{\dir{cpp/}} This directory contains the C++ front-end. It supports the subset of C++ commonly found in embedded and system applications. Consequentially it doesn't have full support for templates and many of the more advanced and obscure C++ features. The subset of the language that can be handled is being extended over time so bug reports of programs that cannot be parsed are useful. The functionality is very similar to the ANSI C front end; parsing the code and converting to goto-programs. It makes use of code from \dir{langapi} and \dir{ansi-c}. \subsubsection{\dir{goto-programs/}} Goto programs are the intermediate representation of the CPROVER tool chain. They are language independent and similar to many of the compiler intermediate languages. Section \ref{section:goto-programs} describes the \code{goto\_programt} and \code{goto\_functionst} data structures in detail. However it useful to understand some of the basic concepts. Each function is a list of instructions, each of which has a type (one of 18 kinds of instruction), a code expression, a guard expression and potentially some targets for the next instruction. They are not natively in static single-assign (SSA) form. Transitions are nondeterministic (although in practise the guards on the transitions normally cover form a disjoint cover of all possibilities). Local variables have non-deterministic values if they are not initialised. Variables and data within the program is commonly one of three types (parameterised by width): \code{unsignedbv\_typet}, \code{signedbv\_typet} and \code{floatbv\_typet}, see \file{util/std\_types.h} for more information. Goto programs can be serialised in a binary (wrapped in ELF headers) format or in XML (see the various \code{\_serialization} files). The \prog{cbmc} option \code{--show-goto-programs} is often a good starting point as it outputs goto-programs in a human readable form. However there are a few things to be aware of. Functions have an internal name (for example \code{c::f00}) and a `pretty name' (for example \code{f00}) and which is used depends on whether it is internal or being presented to the user. The \code{main} method is the `logical' main which is not necessarily the main method from the code. In the output \code{NONDET} is use to represent a nondeterministic assignment to a variable. Likewise \code{IF} as a beautified \code{GOTO} instruction where the guard expression is used as the condition. \code{RETURN} instructions may be dropped if they precede an \code{END\_FUNCTION} instruction. The comment lines are generated from the \code{locationt} field of the \code{instructiont} structure. \dir{goto-programs/} is one of the few places in the CPROVER codebase that templates are used. The intention is to allow the general architecture of program and functions to be used for other formalisms. At the moment most of the templates have a single instantiation; for example \code{goto\_functionst} and \code{goto\_function\_templatet} and \code{goto\_programt} and \code{goto\_program\_templatet}. \subsubsection{\dir{goto-symex/}} This directory contains a symbolic evaluation system for goto-programs. This takes a goto-program and translates it to an equation system by traversing the program, branching and merging and unwinding loops as needed. Each reverse goto has a separate counter (the actual counting is handled by \prog{cbmc}, see the \code{--unwind} and \code{--unwind-set} options). When a counter limit is reach, an assertion can be added to explicitly show when analysis is incomplete. The symbolic execution includes constant folding so loops that have a constant number of iterations will be handled completely (assuming the unwinding limit is sufficient). The output of the symbolic execution is a system of equations; an object containing a list of \code{symex\_target\_elements}, each of which are equalities between \prog{expr} expressions. See \file{symex\_target\_equation.h}. The output is in static, single assignment (SSA) form, which is \emph{not} the case for goto-programs. \subsubsection{\dir{pointer-analysis/}} To perform symbolic execution on programs with dereferencing of arbitrary pointers, some alias analysis is needed. \dir{pointer-analysis} contains the three levels of analysis; flow and context insensitive, context sensitive and flow and context sensitive. The code needed is subtle and sophisticated and thus there may be bugs. \subsubsection{\dir{solvers/}} The \dir{solvers/} directory contains interfaces to a number of different decision procedures, roughly one per directory. \begin{description} \item[prop/]{The basic and common functionality. The key file is \file{prop\_conv.h} which defines \code{prop\_convt}. This is the base class that is used to interface to the decision procedures. The key functions are \code{convert} which takes an \code{exprt} and converts it to the appropriate, solver specific, data structures and \code{dec\_solve} (inherited from \code{decision\_proceduret}) which invokes the actual decision procedures. Individual decision procedures (named \code{*\_dect}) objects can be created but \code{prop\_convt} is the preferred interface for code that uses them.} \item[flattening/]{A library that converts operations to bit-vectors, including calling the conversions in \dir{floatbv} as necessary. Is implemented as a simple conversion (with caching) and then a post-processing function that adds extra constraints. This is not used by the SMT or CVC back-ends.} %%%% \item[dplib/]{Provides the \code{dplib\_dect} object which used the decision procedure library from ``Decision Procedures : An Algorithmic Point of View''.} \item[cvc/]{Provides the \code{cvc\_dect} type which interfaces to the old (pre SMTLib) input format for the CVC family of solvers. This format is still supported by depreciated in favour of SMTLib 2.} \item[smt1/]{Provides the \code{smt1\_dect} type which converts the formulae to SMTLib version 1 and then invokes one of Boolector, CVC3, OpenSMT, Yices, MathSAT or Z3. Again, note that this format is depreciated.} \item[smt2/]{Provides the \code{smt2\_dect} type which functions in a similar way to \code{smt1\_dect}, calling Boolector, CVC3, MathSAT, Yices or Z3. Note that the interaction with the solver is batched and uses temporary files rather than using the interactive command supported by SMTLib 2. With the \code{--fpa} option, this output mode will not flatten the floating point arithmetic and instead output the proposed SMTLib floating point standard.} \item[qbf/]{Back-ends for a variety of QBF solvers. Appears to be no longer used or maintained.} \item[sat/]{Back-ends for a variety of SAT solvers and DIMACS output.} \end{description} \subsubsection{\dir{cbmc/}} \label{section:CBMC} This contains the first full application. CBMC is a bounded model checker that uses the front ends (\dir{ansi-c}, \dir{cpp}, goto-program or others) to create a goto-program, \dir{goto-symex} to unwind the loops the given number of times and to produce and equation system and finally \dir{solvers} to find a counter-example (technically, \dir{goto-symex} is then used to construct the counter-example trace). \subsubsection{\dir{goto-cc/}} \label{section:goto-cc} \dir{goto-cc} is a compiler replacement that just performs the first step of the process; converting C or C++ programs to goto-binaries. It is intended to be dropped in to an existing build procedure in place of the compiler, thus it emulates flags that would affect the semantics of the code produced. Which set of flags are emulated depends on the naming of the \dir{goto-cc/} binary. If it is called \prog{goto-cc} then it emulates GCC flags, \prog{goto-armcc} emulates the ARM compiler, \prog{goto-cl} emulates VCC and \prog{goto-cw} emulates the Code Warrior compiler. The output of this tool can then be used with \prog{cbmc} or \prog{goto-instrument}. \subsubsection{\dir{goto-instrument/}} \label{section:goto-instrument} The \dir{goto-instrument/} directory contains a number of tools, one per file, that are built into the \prog{goto-instrument} program. All of them take in a goto-program (produced by \prog{goto-cc}) and either modify it or perform some analysis. Examples include \file{nondet\_static.cpp} which initialises static variables to a non-deterministic value, \file{nondet\_volatile.cpp} which assigns a non-deterministic value to any volatile variable before it is read and \file{weak\_memory.h} which performs the necessary transformations to reason about weak memory models. The exception to the ``one file for each piece of functionality'' rule are the program instrumentation options (mostly those given as ``Safety checks'' in the \prog{goto-instrument} help text) which are included in the \prog{goto-program/} directory. An example of this is \file{goto-program/stack\_depth.h} and the general rule seems to be that transformations and instrumentation that \prog{cbmc} uses should be in \dir{goto-program/}, others should be in \dir{goto-instrument}. \prog{goto-instrument} is a very good template for new analysis tools. New developers are advised to copy the directory, remove all files apart from \file{main.*}, \file{parseoptions.*} and the \file{Makefile} and use these as the skeleton of their application. The \code{doit()} method in \file{parseoptions.cpp} is the preferred location for the top level control for the program. \subsubsection{\dir{linking/}} Probably the code to emulate a linker. This allows multiple `object files' (goto-programs) to be linked into one `executable' (another goto-program), thus allowing existing build systems to be used to build complete goto-program binaries. \subsubsection{\dir{big-int/}} CPROVER is distributed with its own multi-precision arithmetic library; mainly for historical and portability reasons. The library is externally developed and thus \dir{big-int} contains the source as it is distributed. This should not be used directly, see \file{util/mp\_arith.h} for the CPROVER interface. \subsubsection{\dir{xmllang/}} CPROVER has optional XML output for results and there is an XML format for goto-programs. It is used to interface to various IDEs. The \dir{xmllang/} directory contains the parser and helper functions for handling this format. \subsubsection{\dir{floatbv/}} This library contains the code that is used to convert floating point variables (\code{floatbv}) to bit vectors (\code{bv}). This is referred to as `bit-blasting' and is called in the \dir{solver} code during conversion to SAT or SMT. It also contains the abstraction code described in the FMCAD09 paper. \section{Data Structures} This section discusses some of the key data-structures used in the CPROVER codebase. \subsection{\code{irept}} \label{section:irept} There are a large number of kind of tree structured or tree-like data in CPROVER. \code{irept} provides a single, unified representation for all of these, allowing structure sharing and reference counting of data. As such \code{irept} is the basic unit of data in CPROVER. Each \code{irept} contains\footnote{Or references, if reference counted data sharing is enabled. It is enabled by default; see the \code{SHARING} macro.} a basic unit of data (of type \code{dt}) which contains four things: \begin{description} \item[\code{data}]{A string\footnote{When \code{USE\_DSTRING} is enabled (it is by default), this is actually a \code{dstring} and thus an integer which is a reference into a string table}, which is returned when the \code{id()} function is used.} \item[\code{named\_sub}]{A map from \code{irep\_namet} (a string) to an \code{irept}. This is used for named children, i.e. subexpressions, parameters, etc.} \item[\code{comments}]{Another map from \code{irep\_namet} to \code{irept} which is used for annotations and other `non-semantic' information} \item[\code{sub}]{A vector of \code{irept} which is used to store ordered but unnamed children.} \end{description} The \code{irept::pretty} function outputs the contents of an \code{irept} directly and can be used to understand an debug problems with \code{irept}s. On their own \code{irept}s do not ``mean'' anything; they are effectively generic tree nodes. Their interpretation depends on the contents of result of the \code{id} function (the \code{data}) field. \file{util/irep\_ids.txt} contains the complete list of \code{id} values. During the build process it is used to generate \file{util/irep\_ids.h} which gives constants for each id (named \code{ID\_*}). These can then be used to identify what kind of data \code{irept} stores and thus what can be done with it. To simplify this process, there are a variety of classes that inherit from \code{irept}, roughly corresponding to the ids listed (i.e. \code{ID\_or} (the string \code{"or''}) corresponds to the class \code{or\_exprt}). These give semantically relevant accessor functions for the data; effectively different APIs for the same underlying data structure. None of these classes add fields (only methods) and so static casting can be used. The inheritance graph of the subclasses of \code{irept} is a useful starting point for working out how to manipulate data. There are three main groups of classes (or APIs); those derived from \code{typet}, \code{codet} and \code{exprt} respectively. Although all of these inherit from \code{irept}, these are the most abstract level that code should handle data. If code is manipulating plain \code{irept}s then something is wrong with the architecture of the code. Many of the key descendent of \code{exprt} are declared in \file{std\_expr.h}. All expressions have a named subfield / annotation which gives the type of the expression (slightly simplified from C/C++ as \code{unsignedbv\_typet}, \code{signedbv\_typet}, \code{floatbv\_typet}, etc.). All type conversions are explicit with an expression with \code{id() == ID\_typecast} and an `interface class' named \code{typecast\_exprt}. One key descendent of \code{exprt} is \code{symbol\_exprt} which creates \code{irept} instances with the id of ``symbol''. These are used to represent variables; the name of which can be found using the \code{get\_identifier} accessor function. \code{codet} inherits from \code{exprt} and is defined in \file{std\_code.h}. They represent executable code; statements in C rather than expressions. In the front-end there are versions of these that hold whole code blocks, but in goto-programs these have been flattened so that each \code{irept} represents one sequence point (almost one line of code / one semi-colon). The most common descendents of \code{codet} are \code{code\_assignt} so a common pattern is to cast the \code{codet} to an assignment and then recurse on the expression on either side. \subsection{\code{goto-programs}} \label{section:goto-programs} The common starting point for working with goto-programs is the \code{read\_goto\_binary} function which populates an object of \code{goto\_functionst} type. This is defined in \file{goto\_functions.h} and is an instantiation of the template \code{goto\_functions\_templatet} which is contained in \file{goto\_functions\_template.h}. They are wrappers around a map from strings to \code{goto\_programt}'s and iteration macros are provided. Note that \code{goto\_function\_templatet} (no \code{s}) is defined in the same header as \code{goto\_functions\_templatet} and is gives the C type for the function and Boolean which indicates whether the body is available (before linking this might not always be true). Also note the slightly counter-intuitive naming; \code{goto\_functionst} instances are the top level structure representing the program and contain \code{goto\_programt} instances which represent the individual functions. At the time of writing \code{goto\_functionst} is the only instantiation of the template \code{goto\_functions\_templatet} but other could be produced if a different data-structures / kinds of models were needed for functions. \code{goto\_programt} is also an instantiation of a template. In a similar fashion it is \code{goto\_program\_templatet} and allows the types of the guard and expression used in instructions to be parameterised. Again, this is currently the only use of the template. As such there are only really helper functions in \file{goto\_program.h} and thus \code{goto\_program\_template.h} is probably the key file that describes the representation of (C) functions in the goto-program format. It is reasonably stable and reasonably documented and thus is a good place to start looking at the code. An instance of \code{goto\_program\_templatet} is effectively a list of instructions (and inner template called \code{instructiont}). It is important to use the copy and insertion functions that are provided as iterators are used to link instructions to their predecessors and targets and careless manipulation of the list could break these. Likewise there are helper macros for iterating over the instructions in an instance of \code{goto\_program\_templatet} and the use of these is good style and strongly encouraged. Individual instructions are instances of type \code{instructiont}. They represent one step in the function. Each has a type, an instance of \code{goto\_program\_instruction\_typet} which denotes what kind of instruction it is. They can be computational (such as \code{ASSIGN} or \code{FUNCTION\_CALL}), logical (such as \code{ASSUME} and \code{ASSERT}) or informational (such as \code{LOCATION} and \code{DEAD}). At the time of writing there are 18 possible values for \code{goto\_program\_instruction\_typet} / kinds of instruction. Instructions also have a guard field (the condition under which it is executed) and a code field (what the instruction does). These may be empty depending on the kind of instruction. In the default instantiations these are of type \code{exprt} and \code{codet} respectively and thus covered by the previous discussion of \code{irept} and its descendents. The next instructions (remembering that transitions are guarded by non-deterministic) are given by the list \code{targets} (with the corresponding list of labels \code{labels}) and the corresponding set of previous instructions is get by \code{incoming\_edges}. Finally \code{instructiont} have informational \code{function} and \code{location} fields that indicate where they are in the code. \end{document} cbmc-cbmc-5.6/doc/html-manual/000077500000000000000000000000001301406513700161565ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/html-manual/api.shtml000066400000000000000000000175701301406513700200120ustar00rootroot00000000000000

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);

__CPROVER_isnan, __CPROVER_isfinite, __CPROVER_isfinite, __CPROVER_isfinite, __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 (C++ only)

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

__CPROVER::signedbv (C++ only)

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

__CPROVER::fixedbv (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_.

cbmc-cbmc-5.6/doc/html-manual/architecture.shtml000066400000000000000000000055741301406513700217240ustar00rootroot00000000000000

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:

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:

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);
}

cbmc-cbmc-5.6/doc/html-manual/binsearch.c000066400000000000000000000004211301406513700202550ustar00rootroot00000000000000int 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; } cbmc-cbmc-5.6/doc/html-manual/boop-example/000077500000000000000000000000001301406513700205465ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/html-manual/boop-example/driver.c000066400000000000000000000014441301406513700222100ustar00rootroot00000000000000#include "driver.h" extern int dummy_major; int locked; int init_module (void) { locked = FALSE; } void cleanup_module (void) { } 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 */ } unsigned int dummy_read (struct file *filp, char *buf, int max) { int n; if (locked) { n = nondet_int (); __CPROVER_assume ((n >= 0) && (n <= max)); /* writing to the buffer is not modeled here */ return n; } return -1; } int dummy_release (struct inode *inode, struct file *filp) { if (locked) { MOD_DEC_USE_COUNT; locked = FALSE; return 0; } return -1; } cbmc-cbmc-5.6/doc/html-manual/boop-example/driver.h000066400000000000000000000007461301406513700222210ustar00rootroot00000000000000#ifndef __DRIVER_H__ #define __DRIVER_H__ #define MODULE #include "modules.h" #define TRUE 1 #define FALSE 0 #define BUF_SIZE 255 extern int init_module (void); extern void cleanup_module (void); extern int dummy_open (struct inode*, struct file*); extern unsigned int dummy_read (struct file*, char*, int); extern int dummy_release (struct inode*, struct file*); /* Functions for SATABS */ int nondet_int (); unsigned int nondet_uint (); unsigned char nondet_uchar (); #endif cbmc-cbmc-5.6/doc/html-manual/boop-example/kdev_t.h000066400000000000000000000006361301406513700222000ustar00rootroot00000000000000#ifndef __KDEV_T_H__ #define __KDEV_T_H__ #define MINORBITS 8 typedef unsigned short kdev_t; #define MAJOR(dev) ((dev) >> MINORBITS) #define MINOR(dev) ((dev) % 256) #define NODEV 0 typedef unsigned int mode_t; typedef unsigned int loff_t; struct inode { kdev_t i_rdev; }; struct file { mode_t f_mode; loff_t f_pos; }; struct data { int size; char *content; }; #endif cbmc-cbmc-5.6/doc/html-manual/boop-example/modules.h000066400000000000000000000006551301406513700223750ustar00rootroot00000000000000#ifndef __MODULES_H__ #define __MODULES_H__ #include "kdev_t.h" extern int usecount; #define MOD_INC_USE_COUNT (usecount = usecount + 1) #define MOD_DEC_USE_COUNT (usecount = usecount - 1) #define MOD_IN_USE (usecount != 0) #define ENODEV 0xf #define MAJOR_NUMBER 42 extern int register_chrdev (unsigned int, const char *); extern int unregister_chrdev (unsigned int, const char *); #endif cbmc-cbmc-5.6/doc/html-manual/boop-example/spec.c000066400000000000000000000025421301406513700216470ustar00rootroot00000000000000#include "driver.h" int usecount; int dummy_major; int register_chrdev (unsigned int major, const char* name) { usecount = 0; if (major == 0) return MAJOR_NUMBER; return major; } int unregister_chrdev (unsigned int major, const char* name) { if (MOD_IN_USE) { ERROR: __CPROVER_assert(0, "MOD_IN_USE in unregister_chrdev"); } else return 0; } int main () { int rval; int size; struct file my_file; char *buffer; /* we do not model this buffer */ struct inode inode; unsigned int count; unsigned char random; int lock_held = 0; dummy_major = register_chrdev (0, "dummy"); inode.i_rdev = dummy_major << MINORBITS; init_module (); /* assign arbitrary values */ my_file.f_mode = nondet_uint (); my_file.f_pos = nondet_uint (); do { 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; } } while (random || lock_held); cleanup_module (); unregister_chrdev (dummy_major, "dummy"); return 0; } cbmc-cbmc-5.6/doc/html-manual/c_to_ir.svg000066400000000000000000001321121301406513700203150ustar00rootroot00000000000000 cbmc-cbmc-5.6/doc/html-manual/cbmc-loops.shtml000066400000000000000000000155641301406513700213000ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/cbmc.shtml000066400000000000000000000310171301406513700201350ustar00rootroot00000000000000

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. 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 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 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.

cbmc-cbmc-5.6/doc/html-manual/cegar-1.png000066400000000000000000000733051301406513700201130ustar00rootroot00000000000000‰PNG  IHDR¥ëÉ÷‰/iCCPICC Profilexc``2ptqre``ÈÍ+) rwRˆˆŒR`¿ÀÀÁÀÍ Ì`Ì`˜\\ààÃyùy© |»ÆÀ¹¬ 2 UŽ +¹ ¨¨ê¥¤'300ÙÙå%@qÆ9@¶HR6˜½Ä. rвùÒ!ì+ v„ýÄ.z¨æ H}:˜ÍÄb'AØ2 vIjÈ^çü‚Ê¢ÌôŒ#Ç”ü¤T…àÊâ’ÔÜbϼäü¢‚ü¢Ä’Ô Zˆû@º! A!¦ahii¡ ¥"ŠˆqŸÁáË(v!†°(¹´¨ Êcd2f` ÄG˜1G‚Á)Ë„˜I/Ãþ©15C}†}sïPoæ³åé pHYsaa¨?§i IDATxì¼]ÅñǧÅÝ!AZ‚— ‚[ -R\Š/‚…ÁBp .Á] Å‹»+Aÿ8ç¿ß ¿›Íɽ÷ÝççÞ;ó>÷sÖwVfgvvv¼_~ù%o¼ñB–eáå—_ßÿ}Ì<óÌa¦™fÒ§?ŽÇ€cÀ1Щ‚ôÃ?„¡C‡†^½z…SN9%\vÙeaÑE k®¹fxõÕW­­øÖ÷ô=ýNãñ‰ %“ŸÆIß_áõ†É¿§ß Ÿ¯oÂ:8ŽÇ@100^œœ³«¯¾:l´ÑFáµ×^ óÌ3˜ï¾û.ì±ÇF°Î:ë¬0ñÄ›;D¬0Ù— SɽZZµúAèÆ| Þ™ùÔZçp 8mÃÀ„ÿûßÿÂ>ûî L$¢ò›ßü&ì¶ÛnáœsÎ Ÿ}öY@”y£0^ücâ¿ûî»- ñyä‘0Ùd“…õÖ[/,¸à‚á§Ÿ ×_w}èÝ»wxüñÇÃÿûß°×^{…¯¾ú*Œ1ˆߤ“N –^zéRÉŸ|òÉpÓM7âÚk¯þïÿþ/L9å”a©¥– W]u•qo>ú¨•‡²ýûßÿ·ÞzkøòË/-qYd‘ðÓO?…o¼1Ì=÷ÜáùçŸÏ>ûlXxá…ÃÊ+¯|ðÁ@>SO=uØtÓMÃì³Ï^±-Ò_ŽÇ€c Ó00þÇÞ|ãͰÄKX&©x óÏþ3Ì8ãŒæA J<ð@èÛ·o9rdX|ñÅÃçŸZh¡ðÊ+¯„ '˜0 ><ì´ÓNF”æŸ~#0Gq„‰ É "¶Ì2ËX:¤ùŸÿüÇÊ0ùä“A„¸Ê*«„7ÞxïpöÙg‡]vÙÅÒƒØ=÷ÜsF¬(ËrË-¨Ç&›lbŠðSDø#–Ü|óÍüàƒ¬¼ûï¿8ùä“ ,Ç€cÀ1P LWÀ ½é‰Ø`r—ßùæ›/}ôÑaª©¦² ŽNgÏ=÷´ô¾ùúó‡+‚[À}ôÑG%"¼ä’KŒ¸\|ñÅá¨£Ž²¸¤¿ä’KÚþ0Ë,³Øó¸ãŽ3Q"D ®kà 74wûaï¾û®qkpBä·Ùf›™ÿ‡~þõ¯…Ýwßݾïºë®ðü£T¯|ý,ÿs 8Ž.Å€):#¢²rðÎ;‰àýÛo¿5‚AwÕ¯_¿ðÒK/…/¾ø"üüóÏaÀê È 3ÌPJ§OŸ>&^{ÿý÷ÃC=haù7Ûl³… 6ØÀDy|É­¾ú꥽-ÄqpHˆÅEN@}à b±§Ÿ~z#¢*+bAíC)Ž?ŽÇ€c {10>b4àÅ_´'“¶&nDbsÍ5WxóÍ7ÍODÉ>⿉&š¨· &˜ÀˆÜ„kši¦QPS5—²„'œp¨Hñ£¥H¹2¾)›ò¤Lp?iÃyÍ:ë¬á´ÓN³}¡]vÙÙö“Tv•ޣÔ"YúŽ~|+mÂ:8ŽÇ@÷c`|ˆJì1ICXÄA Ц›nº±JJ8 â0&z…‡KBYbÚi§ ßG5s¹yÎ9ç4UsÎAATÔÍçwãbÏ¡€à·uÑE•Õ$“Lb~üûñÇÉ'ž?üð€Øo5Ö‹Ç}ªgžy¦§|ˆC½(³€²ýö·¿ÕçXaKŽþâp 8]Š ™œÙgh0Ù³‡òØc™J8Zy¦y—ÛSšx’‰Ãm·ÝfÊœgBîÐC5qÄàñH°Ö[wÝReæwÞ°ÖZk…8À ØûAù€}!8ªí·ß>¬´ÒJF ( ÚvÄ@km9€ôQ¾ O!ÐÖƒ¨hú‘{Nˆhþ±Ÿ%àlÖ=÷Ü£O#È)+yø‹cÀ1àp t&ˆ„dûB[o½µMð‰k¯½ÖÔª‡ b\„‹ [“6œÒ÷?`Úv(<œqƦuÇÜþýû›h né÷¿ÿ½)(…´í»]pÁÆ 4ÈÔÈ!<={ö Ë.»l@‘áᇶtHcŽ9æ0Åö¢Ø#‚@R4úà¬à¦ LpKË/¿|6l˜7”0P GÄ@„à ‰G=øF‹ÍÁ´n]†yÏÈ1àp 8ÆÁ€ž…hˆàp& "îñÈŸz7ÄŒóBh¶! Cy (žp3pcĵ &„Ö¨Q£B¿¨8Ä9¥”„îâEzpL㋇•ÆÓ»âëÛŸŽÇ€cÀ1P Ø& G5¼@n"HéáYþ€ÔÉ7ù)nš‡¸…óa¯i±Å ×\s‰ßlç”ÒóS¤¡q!špR„ M?©Žó­°ø+/¹¥ßø;8ŽÇ@÷cÀ8¥´š¬qc¯W^y¥iß­¿þúcMø•§îʃôyç añ!J«­¶š¥–¸/¥«´ø®Vn…÷§cÀ1àp ã¥Z‹ˆJ5PMLVkZ"L„‡8ñ­tS¿ZÓópõ‡Ú9åÜòaÒïJ‹‘Jîi\w 8Š6¥Ž,¾žJ;ÿ-wÖj!,]A4ŠRŽúi9/©c {0ЭD)%:•Þ»-žkk1@ûiâ‡È´–аGÉc ?þôcøéÇŸLT‡œ•~¹<È‹}I¸k΢q¨›'{Žì3Ja§Ö:)/·¥.µæãáŽq1ЭD Ë^xaXqÅíÐ-¢;&‡âb@D!-a%A¡ybc¸Ÿ|ò‰í¢ØB{C< DX›' î"D OúaõN˜ütH“ò×XáñÕ¿8ž€Zš(Æ í)‚V©ÿµ¦Þ)nüÝ1àhº(1È™<0o4(žWÂx*çˆ4q´®º³0 ®¡ÇáùôÓOKDƒulŸÉõ™ŸâlÄ‚ÇÐø„ˆD_þúᦧˆ„ʇ;}G?Üõ¡ƒèqÜŠü°¨<ð£üpUôAÎ×Q^¾)#v+ò'-•¯RXww 8ZÆ@·%ŠÆ€f s¹à~ûíg×Z8aj¹Ñ:3mðÌs ¸Á0©³˜€è0ñ3Ù¿õÖ[f9ž ³fLèp$hO•ÈÚ{g–½­icíƒ:Á©!Büæ›oì08ý >”ΫGF´à® ¤y"NzæÃø·cÀ1PÝJ”(ƒ˜É €«$Ž?þx3y$÷ÊEwŸŽÀ„¦"mܹ¡¢Y(l2icŠ6ƒ‹Àr &lön±UÒk/¤}G§—/˜ÚpUôO,‡p°€™fšÉvà J˜Oƒ2ò£ÜiÙóáüÛ1àn'JC­\¾w '8aêΉ2Ï ±GƒE ÛbuÎáå—_6ÂÃÁf¸Äm:ü\©ˆ´§@±žr/ÒSÄMOÊ–ÇMZ^ˆ\"ÄÑ·!ƒ7¸D8(Œ/°Àfe$M'M¿ÈøHëêÆ@!ˆ•N Óh6ðX‘˽«ÓHù‰1æ'C®'a?…›¹ºž{¬0ÙÄ»€Ú[Éã#`S¿|ú©_½½×ZGú(ܸä¸ö® T(ñ þÃlœe j—”p¥þþîhF †(| 8&ö˜¸žÂ SÛ»e¹Ic«ð‰'ž0»($€ã¥—^Ú&NDq•öJ(I9ÂÖöÖoLá¶>Ø—âbKpýÀ˜ ³Xܪœ'P´K¥´êK^rÇ@ë1P(¢DñSÂÇÄYî­¯bsÅ(7¹¡}öÞ{ï7Ä ¿ˆßà€ DlÜ#rJ!Ï!4÷“Ö³#ß«á ±({Qp£Ï>ûLõ}¾þúë°òÊ+‡žÑ:>‹‚”–ã=ÅŠ¿7  G”@¼Ð+¯¼b{L't’¦*=ÒVí!jË7æŒ8dc^wN1 ®²Ê*†G&BÎå¤PŽ˜¥þþÞ: X›TPp@qmEÚç®»î2‡ÊÕ.2nLnNœZ‡sÝ($Qµ)a:è ƒœc*Óß„£Ô‹ x1Á±7Ä=Sìi¤„Hq}Ežb°ãßS\çñvš|p°\Âzú€Âï~÷;k3•Fix[ #þlT –(pMºpL¨‹³Ç䢼1xQ§dÿ‚›‚_xá…ðú믇UW]Õ.3dƒ=&6~¾±žb¥ëßÕ˜”È@ h¿§žzÊöüÐà[tÑEí2J™JrâÔõíå9v- M”@…ªÉ|°°}öÙKî]‹®îË­Üd„øŽˆ34ëå–[ÎVØšÀ(­âñžN€|;t?*µ">nV†@qV¬OŸ>¶èâ½îo3/Açb ðD‰ê§„ Žéä“O)aÒÀnÄI7_76Ì9ÄÊ+ˆzZh!3Õ£®B~Î #õóT_OKŒH–½A ì.»ì²ÆA©}‰“çºÒøþî¨' ÔQ¡¬pL‡rˆí1A˜ÐlÒ^ q£&ÕW {rLJ¨r³)þ‡?üÁDtš˜D¼ß(8PÝ›ñY®=9 Å~áÃ?l†mYp–lŠ)¦(¡(?òý¨Ð_Å@Ý%ð§a:à€J{LœªÇØ'f_òƒ² x¯X¬|ùß|óÍpÏ=÷DUâgÃJ+­d«dÌÚÀ‰¯’…Æ|Š@¥‹ úÅ}÷ÝgûˆK-µ”ÒU¿ IÆù'¼€³k®¹ÆTöé\zØ]?ù’?ÖÞyç÷íw߆7^ÃúG)X´ug?KI9(WpkÓM7µ{»(wQʘ–×ß;uM”è´u^´Öà<W°É‹ûh?ÂÆåXA å†4øT‡î*¢ÊAÙ ’çwžÙf›mº«H…ÎWø‚ÿç?ÿiý "ÎÂBûšÝզ騉´©„(ŸÊÞÝV9(ïh^ýõáˆ#ްK%åßÝåôü»uM”„&u\V[‡zhØ|óÍME\þþl;;찀ؕ{á¹í©5VLá.öÛzë­«‚ÝTöXËo»í¶ÝT϶;10殃î,Eå ûUl&P€I#}óÔÊ,õç]aôž~çÃê›0ùpùo…Õ³\ùu÷“²±ªP¹ÿþûí½»Vý–yÿ Ü“„¨ _µÀ7ñôSßÑ“ôòïéw¹üð/WÜÓ¸é{¹tºÒMåå˜6ÿ¾üòK˾HeìJ|4k^ G”¦›n:kK:¸& 5.ßrOÕ±åÏ“0ìípæ‰÷|iXÞ0 Ç»&ó–â)N>½"|§eC› Gå1@›³/¨~G¿j-€oâéÇ·ú•Ò³H~øQ‹}RqTú¼&ü´m ÇwQ@ea/ |"ùph> Ô­Jx¹¦bàqŠPχc Btàª8ÓTNÝšMâçž{Î&cTjó„Ò”;Jlrß}÷Ý%¢´ï¾û†Å[¬b\¥QOMnõPÖî*£ú[äCâÎeë'zú#?ú7ÑJQBéR/´3GŽiý ë êù:Ëû™.¿ür3ÞË?ùä“›ö]ϨL€ÈqÁ4k ŸO§¥oÅ5j”YÙpà M‘Bî-ůäOÓzW çî‰Ö/ëê ·+¯¼2pÍúqÇWZ‰ÉŸ0zç "D†Í‘;a¾qg"Y}õÕízý÷ß?p!!ÚC( «ŸÜxÊ-}¦îµ„-žô¼C¬•Gêžw“_þ™¦—÷óïÆ >ç1î§ðŠ»í¶Û΃o¼ñÆaÈ!&ºJûaYp…:ŠpMå&nÂáÎu&ÒÄN$g–0A„•y¸ùË.»,¼ýöÛV(â¨,*åh·1‡sÇv'ü?ÊÂ;¿(—žâ×ülkNÓÖŠSj ã V›¬@å5nLâœå@¶ÍIøõ×_߭“ïhçƒð'O¬T f°¯ÃÆ/œWg£í¥r↠Œ\ ÷õ×_[Y˜¼î½÷^›Ä(/«dâq®†Ã»ØÌ×Kyú³ó1@{l´ÑFfˆÜ¦šj*ëOlô«­òíÁzúé§­ÝÊ€çŸ>\{íµa“M6± ý’@z¿ü2zaÅÞ)çû Tò£п0Œ-FîpEô'¸5â èãJŸ¾G_Ó·ÂøÓ1P š‚( Üâ’ô-ÿü¹>ª©Lò@><ëSN9¥ùë| ƒWa¹ÿhŸ}ö \éÎ^NÙkß‹‰ƒ ‰çÅ_l×qð޼ÿ¬³Î GuÔ¯È/áŠ+®°É SJˆ^¾óÎ;–/VÒQ£Hî bÄDÃÂ$\ecÙ{ï½í õáÇ›y&‹ìÿºôˆ ÄE“8‹Œt¿“6K;w%ÄÑ€úšÂÑö,”PRH›Ÿüqà (ôµóÏ?ßÎÑ_ƒeq,îÓ¿¹P“},€±°Ë.»„»îº+`¥èС¶¨B1=+Ò$ ¸r4ËLKÈÿ9ª` ©Äwy<¤ƒ4ïÇ7ƒ ‹’•çÃ`õîk ÇF#“iÃpðôœsÎ1Q v‡v·ß~»É÷!h1°…¸‘g­^zé%Sm'>ßL@=ãõßþö7›ó öûì³­ŸÀq"Dköpý'žx¢-ÔH88Ú‚±gÓ¶¤PÇqð½3`5)3¨1l)?…Õã–[mµ•­&¹ýSˆžÂDŽ¿À X&í·ßÞdýl:ÿ÷µØ7 ö{vß}w܆ èú¾)Ó /laáàØ‡˜|K‹¼'šxâÒ7+XVàBYñ"ï±Ç³‰É‰’¡³ËÿÑfô8“Aƒ…ÓN;͈ î€ú“ Æ"ˆ~)ÎJî Çž&ı] òÇþÄÞ@ÿ‘¡VDÄ,b'c…ppùp_‰áÈÓKéWôÉ^|!¼ûλ–.å«D-€ÿs ”Á@S% ?MäàE„ˆw ^žp ©þmÃÕpV…4ÓH|k p]¨ãÅð„xRùá–O+„(“Ä€Jƒ8LXäÒ%Mqs<‰ûç?ÿ9,±ÄÆ)qQ"+k Íßü_§b€¶ç\]2lذp饗Á!ÓJýbS­_²gŠØö­¸g©ƒäù¾D_K_èKêƒ,žÐ …PÁIÃAQÌw©LêO*'"?¬°Ï„x™Å—÷¥Ní: ›xSî)1 ¥¡ìÀ`e !Š@l¢AÆ“ŠÕç”x¥þ¬VQ@ Â0!Ò`Åʆ/œÀ ôàƒùË_ìî%%4âjÌ3þ£œ"8”AŠ ¬fÏ?xØ`ƒ ,(„Né09°W€è@‹ò°w„莋 “i§*ìÑÿu:h[úi×]w5Q/ý‡‰Ñ0€¥{Ô»S ßп*õKDqì±Ø >y.Ê (ÌðMßN9)únpèh÷‘þ\sÍe\>î0ÎìÝyç&>¦ (ä@´D|èì'±§‰PÿMËïïŽjh NIƒŸ‰¹8Ê zdåÜÈù‡?üÁ6Žùæ‚4-ÀÀC,'1…ÜñSš˜áA ûpÈàgši&¸p!ìÿpx‘•&†&ÙüeJ‚!âÁw*†#/òVžøÝrË-¶ŠF‹ I¶Öð:Å "ŠNf—˜dØ›Zf™eL™‚x¬jÙ´îÑ£‡­ªÙ´fŸBõ¢<‹µ-{ŽôG8ˆ„ûìÞsÏ=¦ ‚z·Ú†~ Á`Q”…aáCúg ½Ù¯DI†w.‘LûiÐ_ôWŽ8 N¤¢ ˆHqÏ=÷´½.üé+žáQQ†¾†²ã…2áFÿ‚ëcSeRúþt TÃ@CdEî ·³Ùf›•pp "Vwpp¬áRøf¥¨AÄ`„TJOá@0“ áYå2@!"8¬&Ñ”cS˜­2—|#aÂ`ËäÃõL.l>wÍ5×´¼˜” j+Y©àâN¹¨#éÔNøÔ?pÁáI&⨠!þÃQ'ˆ!Jãb\CT‡¦ûŠã†¬ìB;ÓÿÔŸÔ~¤GŸ¤}éjuÓn¹¥©+ÜØb\p^ e–žQY†þD_£ÒGHƒoò oäùVäž8/õ%Üé7<á´é7꫌qMäG_KÅ|–X•*7eá¨DE ¹W‰ê^ „¦à”Ô^ Ù(“O:=”_:8ÄÀ¯ n…gEد_¿q‚âÏ`•lŸŠƒ{ úÆŸÉI `Ð3È!jpmâÜ—ÿ»ßýNŸã<‰ÇO@úà‚ Ê¡û11¨,<ø©Í ^,° ÐóöKö  bCŽôõ5ÜÈ‹>%å…“;&ŽRHûªÜËqqòó§c Š(1hÊ Ò„Ƀâ¤ñYBHªÙ#4n¹t5AÈï|œjß ¿ÔRK•Ä5ªƒâ‘¶Ü”Où§~J/uKæñý½k0o åJ[ÉOmyóÍ7Û&Š5øÉ]qô”»âWrOÃég¹x•ÜI;_–ü·òoÍ3_†ÖÄõ°õ‹† JˆX­‰Ó©ÖxåÂÈ‘ {C\Ƚ\¹U SÉ/ï^雕,‡lùp¸—skkxÅóg×` ¥¶ÓäŒXë÷¿ÿ}‰ë®O%¯&ïÞÒw{ÓSüÖ<Ï͇ºÖ¾Ó`… !âB3‚ȯ–&%lq šs¤›º×’–‡q Ô‚|ŸKãäûœF^ œÆi¤w™hª¢äñÑHuõºŒ‹º&J¬˜\á‡~xé-á8·ß~û™v*ß”Wi)?•Uù¤þÊ£–§˜ú†[ÂÊÆ„ÉÓ S-¬Ï0u­~Í5רJ ³'X/Æšƒ´ïª5‡!Üw1¨§œrŠ4ÔA¤‡è“*A®£æ°#âLÁ¥q†sEØ¿Ã΃®†°L0ˆÙØ÷‚ëBƒ Usòä^Lþc †!ñ(yÝxãv€ñü£å ádÕzE\a÷ˆ¦8‰IòÁD eæZmLÉÆQXa—´Ü»DxLµV)ÄómÆ€Ú—³Fpø˜}¢þú׿–7Óvü°a(Ë k­µVéÐ7òÑï!˜¢?ÝqǶxâN.nK†p`ž«"º²ÿþfCû“°î:®£(‡³¹ÔË%qÇŠ=yaéûŽŒ-úÄà¹çž³þÌ8`|š¯Ô‹#"¨ôoÎSaÍ댬CP?ò¬~úy´õˆAƒÇ„µÌ&µ6ZóópÝ‹ºã”Ô1çÃ*“I`ÒáÙ@®ôØ¢ãL×K`N™¹€sgžy¦ äÛ öˆVe3v=ö° ¡SìÃLiÂ=UBÂX Ï¢¨Cÿá›ë$bBß`±BþôY 2Î !ìÝ»w@L¬þˆÿ,³Ìb .¸9.ŒD!΋ÔnœKþWH"úE±:–éáÒXŒ±hÓâ’ôjI/àÖHÒ‡ÆÃ@]qJY6ZM–AÀªŽ‰Ð@ã½¥˜V¬¯½öº™ØGŒ±àêqÄ ˆ*Ø¿ Jˆ¼”&€ÍWVŒG}´&Š“N:É8"Â3!¤›Ô¿ü’Ù‚%r€ü±+†ˆ?,Œ³…° y…øCöù˜dÐ’IŒôµB%-Êa"?TãSûwˆ™ôÀy•‰8ÉÆi¤¸ãÛ¡ã1  Ž„INŽŽCâ8qè´1‹µ;œ:}’'œ „HûQ´?@ý”b?ïLêäÏbñq!$â?@ŸÑ¡Ï±(â™Â@`1VLé«äÁ¢èá‡¶à” n ³Ï>{)mslå?Õ+9àú Ðô_•·•Éyð‚b ®8¥ñÆ}ˆŽýIJ5«V\O=õ¤V‡šü´ "Äi#Òå§½>âb,šTì @©PÀ@‚èˆ ?šW?îž!-Þɇ$Ü“ ‰IiFÖšqSùHƒ5{d¬b&¸!¸*ÊÀSu'žÞ-°ÿë 0‰"‚B˜l ª¤çP,”˜ ÅŦøá°éGà‘¶È÷9RFùö¡mh[D{àž… ú- Ü„r„„½Iı,œÐ£ÿWÄ7@Ÿƒ›‡³bŒÐï2¹3–àžFŽi{W,tè+Ä¡OC¤ˆCæ›>Ç;}qeÈ!5€sÒÕÔ΢I} ¢à‰~ ¤x2‡_Ýèߤ!&? –oö¹Ø³¢àT¸¶þ¯n1P—ü©³1ÙB öÝwß±.ÿ–.ù+R+?äˆ#R`ba¢±Q9 4×¥áÓwD¬rÓýÅ'œ¿ZJ[+SÅKÓ$üwšvúNÝ hàÜ/ùK13ö;ølí%µ¶}âÁœÆSb‚Oûœ6"4‰ÑÆ.å˜/$Hò“¼B°€ÑHnåú>~i™à¼Ó¾¬¸ùp©{þ]é‘J:Õ.ùSÿä¸ ‡ÆÀ@]ˆï4€]IÈNÙ`”ÜS?½‹ é›'“vž ážNä¡8ÊoVÕ bÞå¯É‡oVˆù)nµ´ +B¦xÂ]úÍ»¾•nµ§Ò¨ÆýZÆ€p^Ÿò#µ}D}BOü©Ñ‡'Ä ‚”º•+Eš–Â(ž’¾ñWßχU:¸‹ ¥ñôN8@ßöÑÎŒ=€c, %¶lï¼ÐÎbyôÀ@ቒ:C°¡¨S¦8 Ó—sOÃè]Eßzâžúé]Jßz–s—[š¦Þy—0üxWZò“¿¾y ª¥OGqxæýÒï4œÞSÿ|ž ãÏÑW—žåpS«_šé(žÜÓ¾#µQ¶\Òp «4x¦þŠ/7}×/ GÜü·Ò+÷¬%¬¸%ko‰ñŸ/o¹ôÝ­¸(ýö~  |í•´7ÍFŒO{ òâoYWòÌ÷ƒüw¥ü[ Wοœ[>ýZÂäãTúF¬ÍœÆ~¥pÊ“ý-¢âPÿ(´J8œŽ‡L›s=höT6ˆ‘/8Ð6o!Pê¸Õâ¹ß €/ð® eŒ>}úXµÇ˜Ðþ¡i†R8âçÐz €7Dh ¢d¨±ÐWÅ-a¥%|¯ÏýŠÂsJ ÍvÌq¾ÜĨ‰”}NyŸvúi¦òLgrõ_í8—"H°äÜ ªëãb@ij?hµ+ïkµ÷µ<®¯h{žvÚivæÿrã=m õU4¹©ö­xÞJóAÎßë…Ö¾S‡DÍÕWL÷È­Š9÷ƒRê·ÒB«ÞýÆÆƒ2ìáaí•áZð>v*Íñ%¼€¯N8ÁÔ¬Á—Cë1€”q»Í6ÛØBH¸m)%…Ã: ip°^n-Åuÿâa °DIŠóXïæÐ*Z@r/‡ÊÔU¢<ž¶â"‚‹UÊ¡­ä¦&{Hœƒ‚;•F~å1 ~‡˜Ë ìmàèY>¦»¦ýªG<ïW. ÀZ±#ü3Ö‡ b–Z¤˜¦_kz®{1PØ=%u4,°ò”ZjµN–úqjÛ_íÀڡ}©4vlúx¢²ÿ¦=¸Æ®uçÕ®µ}Nãž1ÏžVñQ~p¨O –(IVŒÑÇÔ˜©Ü[B7Û¡ýЀoJ‚Scײkj×–>'…¬I` ‰R×´UgäRH¢¤•Ö Prຠ5µ5a;±žfóaÀû\÷µ¹pÏ9F ÍbÙ¤£ö“!xسĜZ\e“Š5_•«}5¿Î _)O¹c {…(†aDº-/–+{G¹ZûØÎBÕPÇë¨Ê{:ŽÇ@c`@sº˜RB„0·¢„y3Tα+˜—Ö(o…Oó-çW®<Š[)¼üóqË…/ç–– 13v¹>e¦Ô/Ÿ~w|š(±2Ѧ'ÃÁ1àp T€&î^½æ7²„ëˆyƒIž³hÀÅÊ:ï€&4þÈ›o•A~Ø)LÃÚGò/ Ï¡aL&• Ozœ»D™&¾á •6ucAZâ@L Ëù¯-·ÜÒ Þ*^šfw¿š(qf‹Á€""¯»Ïów 8ÆÅÀ2Ë,k·=ãƒöhGÄM-?îqÂ::†`¹-š;Õ°î¯y C±œ_ãZÎNêâô,"d¸qí–Ú‰Ã-Õœ· R\9ÂU9«¯¾z ]´;1XK´¹bsöÙgÛµ!¤±÷Þ{›;åÁº<åÅ*繸À|!!"¦;Avæ™gfQ%ÜÊÇ·ƒcÀ1਄Ÿ~þ)‹ Ù,^“­»îºÙUW]•Åk7²È9X”ÖÎ! 9˜,Z“Éâ¡^K'Zœ@&˜Å½¥,NôY´æ‘ųQY$打ù_|ñÅY¼N$ãIøxÍXåPú”ÿHä²_z1;î¸ã,½Èee‘ ËâùLó7gqK#‹$ûŽ”fQ©#‹{ïÙùçŸon‘heqO-ÛvÛm- Ê÷Ì/^¯“Åkä3ÊOÞQ)ÄÒ¢P‘ ³²áìf¡@ ï4Êâ-›Y4ßoå“{¡ ë…q 8ºš˜ÄwÙe›€ãõöŒw¦e¸ Wk>O”˜› "Lð‚#Fd;ì°ƒåqüñÇg;ï¼³¼ì Q;òÈ#ít•6ÏxÈ?‹÷¤•ÂCXI?^º˜Eq\Ï Ú»Ä+zÌŸp ÷¨ oÄXaâ^‘…@BÈH/rVòÎ"g•ÅýúB¥ÂißE¬ Œ’2PiЈ-ŽÈup 8% 070op}ÖN=õÔ0çœsÚ%™Üɤk5:j!¯¦ŸÁòP!"q±;®Ø÷áÐ>"=±sç§°˜Äs(`¦ q whI䈘àî,]ÖÈ7yqÁ¡lŽ5ÊDzº ˜òq¹(šˆˆ p¨@8Ów‘ž…#JBÃÍ­Õ‘”®?ŽÆÃ€æ nÂ=üðÃÃÁl•„8LÌy­9óhÃ?&ý 'š°D<Ò$(êâÚRž•ò‡A˜¢¸ÍÎVérOö…PÕ†¨õìÙ³DX”wj‰Ø(æL@¥ùáN¹Ô¡¨P8Eu®Ï>û̈ˆò‹ŠD/—cÀ1Ðý`ž`þØtÓM­0(p®мbíüGZX™IÓdòç"Ãa®i‡ ðÍóž{î)mIËqã‚“Y|ñÅMí<ŠóŒû#]8©4/ÞáþäWDž>úh©f¨Äsñ!é¨Ê× ŽS¢_}õÕÀªÇÁ1àp Ô‚&pœ–ÆÑ†ã®@óJ-é´è*,ŽîsZsÍ5ͨì~ûíÖYgLûî˜cŽQp{ª\‡v˜©gŸtÒI‹q/ÝÄ‚†8§«ˆÚ`Wö V!F“ïè£sÏ=·iòq ¿®qamÅy¡8%Uä¡®ý¤®@¤çáp Ô7 H&&pÔ¹ ì7Þ0‚ÔÒÒ¦™fšÀµ. âÖ·oßpÔQGQÄ*Ý=¢Ù .¸Àöà”´/¤ÉZÏ¥—^Ú¬E Š a÷Ýw·xœ‡‚ƒb¯‰C»néüˆº8jçQÛ/DÕ0ÌÂ?q¦vZ+¯òW:Ê_ßí}2‹[%mÞ5§·”v®PVÂ)•Á¼«§h&0ZB®û;]$¸n€[A¹`Ÿ}ö ƒ ²w…©µtšàŒ9äã:¸V# '÷ô›½%Äo@ê®°é“ò±/T)|KñI‹ýÏ?ÿo‹½”“~#*<ï¼óìZ Öâ&-7ïiº”ôtÈ8õËÇËÇå»pâ; E'`Uâ×pƒ Ç€c 4¡BöÝwß0`À€°òÊ+[Df¸ <Øö¨¶ZzåüX,#DTÆí©í;ü˜xù1oé›g%“ÏCqË…§Ì¤ÅHóJÓÁΊï€â@ù¢J{¸ì²ËÌ®¨üÍ3÷/ŸFλôI8Òáï}÷ÝgZ†WŒâ.·ÜrÆ)*0÷ŽÝyç¦%ɾœÚƒ=°+®¸Â!J|§‚SPG”Vîþt 8)4©A®@hAXÜ"bÃ"¡‡ZºXtšN¹wMØ(+°7Ï@™ÈLb<ù—w¹ë›g­;ñ [.¼éù¼F»ŽvW„á'HÓÀE S5»¢iJWéé‰;á0 ·äRKš‚¢FîbÈí|ó͸|Q€1ØwÜ1|þùçæD¹±Ë2b¢…ØY¬,±ÀY\á´ù$va*äq 8: ‘èXÚqUžEQÿX‡G5—(LÜcÊ6Þxã,*#XÜký)-U„ïZã1œê¡g¾ŒªßOýôÓá„N°½9Ä¢„#-â’(Ç€cÀ1P pIl®sžˆ‚¥0þxÕ…?¨GõåW¦:ÍB¨û¢wl,ƒˆ5Wr¤ðæ›oFb2æÒUü $¨¿£X’Ç£ìëÁM„ùæ›oì–Ì£Ý>SoOã’(Qp: ˆ‚ªrV+ÿçp 45˜˜¢ÑÕ-j›º6“#×2”›+´Gü-kÛF;ZaÕ1 [}›o¾¹ÙòC…|æ™g¶HÂ3œMxëwÞ)á^~±™ ¸:ñ*0Þø£ r­7àÂér.•ó]ÖV²`ÿD”( ƒcÀ1àÈc€9‚ùµbö<† f–D°^‰U?+óí¶ÛÎÔ”™8ýWàÜpÖ ÓEñ !ãl H¸à€(õéÓÇÃÂk eŒE¼BdŒFäO?[˜hÝžˆö0 5dÈšè/&PˆÈÊ fQ…3‹×Û·Ü SP/ˆcÀ1P  9D‹ÚYT5΢IžR¹äÇD[n¹eÏИŸÏ'%ÕüÎòxÓ7ÚwÑjy/Ìâ^ÔXiFëç¦]—×¾Ó7ãÙ% ýR@!ÅwPKNBËê­‘Tÿçp 8r`®ˆ“£Ù{c3žóHÆXñƒCª·¹b´4Îy¥U~.)ÿÌa\ Äé›§¸Röé8ó׃ù£xù¡)ªqH–sJ=£ B@6üØšxbŸïꫯ¶CÉ‘XSÑ}$´?œ(Y»ù?Ç€c  ò„ µo¬põ ¦Ê¸ªÜ RVð*GˆòA†EÀ#¹•YÒ—ÂWÀ h($QRÛ ÂÃ2- '?:Ž">/¾øbXpÁÍ 5c‡úÂ@¡‰ÒK,aKR×À«¯Žå¥u t5D”°(€é‡úÄ@¡‰VißqBpn©>;™—Ú1ÐÙÐÜ8‡©§ž:pΡêìü=ýŽÃ@áÏR5u$ÌT`È‹ 8·DÇ“_K( ¬:jKaÝ\ €çZq=nìæuñ~×ö¶oOŸÓÜÀ¦(8pݶÜÚ^"Ù($Q2OÁÅ]ѽɈká©3ú¤Úþ.%\¶?¥ÆNAxjÏÄÚØª½vÂeí1Æ,d¹C õ‹Â%Ô¯»î:3yŽ6^-–¸œqzöÙg]¥¼ }â‡Ú£Gã–jÁy²i˜()~¸­“[4ZÎ-¼ð­¾mZø÷ú˜½» 7ܰõ™{ŒÂ` ÐD‰Î6묳†Ùf›-¼ð a‘E© q˜P¿ùæ›íðÜd“MfJ¤åÐ2 è\rÿý÷ÛÕǘýŸtÒIkZ ´œzã…ЄøñLJáÇÛao´Fµ€j¼w|ès’òÉ'Ã5×\cw± nkÍñ¥_2.ÉUÁkÅX1Ö(¥èâdÅÕˆ’:0–¹0jÏ=÷4‚–¦ãïµc|^yå•aèСaÿý÷/vq°µ§Ô¸!Õç¾þúk»zýõ×+®¸bãV¸ jöüóÏÛE}ÇsŒ-Š„ãjY«OÞ~Çíá/ù‹•ø¿Z<÷+& ­}'”-½ôÒÆ)qR›HGMA—þ¥—^vÛm7#HyF<óåHËÄ»ÂäŸùp•¾‰GÒø•Âv¤;ùç7ÞØ.ÝbAàP¬î¹DN üu¨/Ôš>áéCú©l­M§Z~JKiW [Íø -´PøÛßþâ5ÚT§R<ñgžyÆú* X ÖýçJéº{÷a ÐDIrÊ)§4OÅUdù½zõ sÎ9§Mäíé˜ uøryR6~Õ¢ÂäŸÕÒÍçEÒøyÿÎø&?]WܧO»â˜|pwƒáãƒ>,œ€,}'̘Pµ½©¿Ñ7jéSÕÂ(GÂPFú~*3O½+|[ŸJ«£Òƒ°¼öÚkE(P­®ãÜfºòÊ+·Þø¿Bc ÐD Ìi_a…ì]Ü*u~TÇÙCªud På_:˜Ëƒ#cC¨TüH… Ä;ü0 0j)iùå—¦¬‘èJ;€ã?š±7BÊc€vdƒž³1ÀxãµmHÑÖ)áHû‡ÞéC2»U­ß©¤„áN²O>ùÄÎúq†Gã w;Vø¶>I“ôT榣xô9pª…‘ÜóOåcìWïçãúwq1жÔ…õÑJˆ{Þ±‡Çu€:d¾(êȵ Ú|\}—ŽŽH L2É$6¸SÈ—EßLætíoí½÷Þö~öÙg‡W^yň™Âåó;b3Ì¥\{íµFIK~ù8ýçZƒöà±£ËTÔôÒ6Iß[S^¤×_½ýÞ~ûí±ú‡Ú€ üW_}5<öØc–tKy=õÔS& Cm½õÖ3‰Â@?dÿh) TæŸâ¡õvÄG”/r/¥C„ħl°ÍH¹whfžX—a ðD LÐÉéhË/¿|‰[ê i05Êòb³U+Ë|~ì@ 1‘OÙ7 GÜO<Ñ´‰Ž:ê¨aBÅIuu↸éwÚé§Ÿn“³) (%Ÿ†×»<ÓoÞÛiZíIÇ㎋µÍ=÷ÜöÛo?ã¤éSÛm·]ÈÝáSð IDAT&…]}õÕMœŠ¶_¹~§p=ôPX|ñÅÃ[ln¼ñÆ0räH[d! ÿñÇíìß§ÿûÔ U®å¦§JŸ~kl 98òÈ#KœWFñ:ú©¼Y¸QÎ3ZÄvt~ž^×a .´ï„Že—]ÖÎ,½ûî»aŽ9æ° ½#;!ƒ¸á†ÂôÓOo?Xp#,"EV­•.Sz"ÙââJnÔeUÜ»wè³Ï>³ú­²Ê*¦^LüJ[ßé3õKßÓ0þÞýHÛæä“O=¢4ðàƒ™k®¹J 2²_…h‹ý+Ô§!Pê‹ÄÓ;{1ýû¯n½õÖЯ_?¼ $bD <ÕTS…I'™ÔÜË¡´lRÚ©ûL`ñqc< Ê¥'¿ŽxRò@*‚BÄ–[niɪŒ‘‡§Ñ}¨ Niô€Ìl@®»îºá¦›n2Œudç§Cˆ4àbàp´52ÿæž{n§ «W˳Àr'ˆ’ˆîï¼óŽåwá…šl76n9>bÄ+"Ä1Tßå`|òüóÏ·•µüXEB, dœÜýYL ôïß?ôø• !6F¼‹²Î¸0zÑ„(›öÿá‡lrVßUxÄÎ?þøCXn¹åÌIܸ¸ Ç„„=*úÏ%—\2Î_ĉC† ±ÅûE"FôÕsÎ9ÇTàŸxâ K?Š*\VXÒü,`ýS>pŒÁù矿TŽÊ“éF ÔQJñ·D§ïÈ+-èä ,ÑÑGmòilí!ÆÓHË wll±ÁÊF2…ræÎàÈðƒP|õÕW–žLBÛo¿½YP`’"º£<(9ðㄪ;À nn«­¶2ÂEx& ˆ(Àù¢3Ï<ÓVɈnn»í6sÏ—Ïý_·b@mòþûï‡aÆ…ùæ›ÏΆ-ºè¢ÖŸÊ-¼° I¿‘vš*@? X»ï¾{é’;ÜõSØ #ÇE~ä ¡AÌG¿~øa'"þC±â²Ë.3wDeœÅB™¥‡ô9¸7wˆSß¾}mqU®ì°ÿ£¤K™W›l²‰¥&<¶#iZ Ô QbPÑ!!k¯½¶ü‡ˆO¯1¨èø 6‰(ÒN¯<ñÇâ„”+Æ)C¤IøÃAHW]uU³–pê©§Z>h?±áÌ^?6£}ôQ›lÖYg³dñ§?ý©d÷OÜùS.” ð‡¨¡–Œlyà†m¶Ùƈœ%ÁàNå§œîÐí ¿!RcQ—‚ˆöJû ‰¢ ô+õ;â¨ß*Nú$];œ ‚Ȱ‡E߇#Ž?þø°ÑFDÇ›m¶™íaÑ!b|°P]sÍ5Ã?þñ0ãŒ3dž½9¤ ,œ bœÛêh ^"tçž{®íÕ²Gæ}»£1ݽéÕ QMêp¬ê³tʶAŠí6Þ1SÄ Ed†¹"q+ä“N„E#ªRþøC,vØa#¬ná\d ‡ i3ÙìÆ @´Â¤£oòMó† él ½¬\É´!‚¢Í7ß<°W×Wik+Þ<^Ç`€6X ¡ƒõ ÜñÏ÷/ý.í„Õ7}ᢋ.Kñ õçMVì̤Ͼ(yi/óöÛo·I"D~ô]ú™§ò®ëƉ‡¸˜ûÏèËÜúªtí¥ƒÿAô0=F~€æ…ÎÆ“ë& Ô•¢8bà10'ÂÊ y²G{pÈÀÄ4œŒ‰sE¬ZeuX_e Kî•ò×yþßÿþw[ #^æÜSLvÜqGÓ”bî w´úd·t©³Ä$|OWÖ„0ÉàŽŒÉʈ›üÞŸÅÀ} ±-ÜúÄ¢À‚$í*1ý©Z¿CôG?FŽEýSOò¡/‘§€>‚;ý‘¾ÆX€¸Q cáØcµ²'í‹J Äj„c?ŠüT'…iÍ“¸ú1é!I`1Š :Оô•¶?‹…ºâ”@†ŽÈf/ò÷[n¹¥]%=#šþóŸMü°Ç{Ø;â0Ô¸ÑÄc8Åaµøßÿþ·"QÔ Ò“|·Ýwß}Æ11)@ P¤Ï CžÏDÀêއÁ0ñ-ø2rŠéaZöøf%‹U 8%ÒC ‘u(&hß“N:ÉöèWpÈ,(ßBhWö"S@ÌFÉ/446è¯púh‡>ðÀÆá.†Eáпú'îôgˆ b»ëo¸Þú!~ç…pbv %ö¡è÷Œ=Ê!Q!œ a؇b¬+öÑŠäKÿHƒwò=ï¼ól¿Œ<Á][ÓoEQF›ÂŤ{Œª™ú á!Hì½ 'D:ˆ’YÌ!ú…x"_â~¶Þzk“BvØaF)#ù!†c‚ ‚`’f¨è”ÂwΞýŽÅžÊ­2Öú$}ŽN@„©g¡Oì§i\Öš–‡«# ÄS—'x+wT=Íâ^½G•é,ªUÛ{ì´V/å}÷ÝwgÑ"¹å#·–2M˕Ɖ+ä,Êó[ŠÞ¢š~$pYœDZŒS.€ÊE@Y•” ânà;.2²¸°0|¤øo ‚h'úrT/E˧¥oú\\ Y8µS)Rî…8‘ Ê¢úv©Œ¹ ?¿øò‹,ã‰b9ðqÜqPóïeç—ô£0‹Ö'²H<‘áeQëÖðC”–êœKÖ?ë uË)±:à\8ÁjÆ ±}meȪq"?@+Ô–òOÃQÒXyòk/>iò„ór(>h/8Œ” WªôúF 1g…KŸŠ£s<©_µwâSN1å8Áðc©¤ý/íë•—s'âjö¨+Î;ï¼¶—$quµ:—KÏÝê u·§”¢Wƒ‡‹è8È^Mµ“ÆmË»9qo¹ùÛDF’º·6] ²êÓÚ4òá5tTzùôý»c1¶¿ÚLmHNê_LÔœ 8p`øío[ZÐT*Ò ¾~•¦îÄKË”÷k)-囯kÍ;DÄQ‡f˜Á4ÿˆ¿÷ÞûT<Øšô=l±1P·œh¥óG–ß(Iá”°Šh ÛGýÓ`cCxÙ>Ëšl›¤åÞžl:"|þ‘f>ÿî Tk+ùA”Øâl ÷–JPk¸|:•âUrÏÇoë7cZ\Ê=œ¹ãl"GAÄýwvÚZv×~ Ô5Q¢ú¬ªèÄ(:p~᫯¾lV by¨ÔñÙf³µVPÚJ¯3f­eñpÅÀúG¾dê/rGÄǯ-ö9å—O¿\ºùxµÄ)—NkÜXôq¾­T ­rHä‚7€ÁXŒÆr4â& ʈˆN‰+´1ç"[f”uß}÷ \)p×]wYØ7ÃJ8×`:&%dÀÿ,&Ô÷ò„€ ûàØéØEèw#ÞvÛmÖñÖUÎèlåaЇ6×UŽ} $Vϵ§`ø¿B`€¢ãþóŸfËÅâƒ6gr§_°(AéæÐCµkHè{p?§œrŠ?ÅŠ=i vÃ*}Ž‚±"=úý™E¶ízôèaçØ+âM9Ñ|–í%%ÌáŠÅØ AƒB¿~ýlŠã " !BL`–1C_<µ`À‰Ò¯Xbr@KNxDw n@Üfùq{íµWM¼‡R+F:w#í²Ë.F.¿üò!b2Ц5ádö…Ûc¹ Ëီ¯æ¢&`•Œ¥fÂA4áܸœ(Å6f°2ðWZi%\i³3Ñ3Q•…PˆH}ñÅè½8" &ˆöoÒõ(]m23‘h£˜2ùˆøÁÙ Cb#?ÂðMY”iÂU19±2fR`Å Â:øG}d«möXwÆ ª—?[úFÈ­Ð.p·)Àý` Ž›½EúžöŸàÆ£—Å :}Ñ¢d¬~£Pw‘HþN¿°H’VýþURwúŸ¾© ô9@ìÇbÕ[‹¦ri¹›c œ(ýŠ4“>À ¼Z]ò$Œˆ«É5ÖXÃÄp¬jS`@¤–BšŽNåCà€˜<Ò‰ƒ=ö€àº „ˆB˜„”åKÃ3ø!ŠˆhòÀê•ò}D‘N”òêÞoˆ“¸®"§ÑθC„±w”„‡}CúD nX¢wïÞaxÜûDdç Å¥)À­§ý¢ÇÕùËrÀ9©ßÑÿõN#@ )ÌÁÝ!‚¦l,¤è«ò·ÀþÏ1Ð\Ñ!"ˆ†,]Zt "~€à•!“«BÄi[Æ}Ä%ˆ*íœíÀ½&äó¬Z5i Æ»öÚk-–žád dÔlC|ìÄã‰8-'ž”`ÿ‹p—\rIˆ×u˜ª.Oö¸Ø—b¥Œ…eÊtÜqÇ™(ÎK×T["þ¯ ?À]h!”ö;8o¸eÚEîÜ‚& íL@áBÁ€°í³Ï>vƉðpÿpÍê{ê?(ÍÄë^lejX`pd÷A «²¡!â ±¤!¾æl@ÿB¤Çââ¤cÈüŸc  L'ÄA-„© o:?qˆ²j0<{FY|zq^Ziü™вK÷eP6`'+vº±“‡!¬‚·Øb ¥!žaõ÷Qc"AdˆÈóH›dÅJšä…HBÙï×edú*ö•ˆCZh5^öØs@”·Øb‹Ù*›3)©°’e£›ÉIuO뙾+ i">¤>å1€‚ }öZ­RQ¿By…ƒÅAãþáRèo½õ–-šè[ô8l&~û‹ì9âF_Ãq€·³OQB1\œ5ß´-?ĺ” ¤%15ñ‰G¿ã‰˜)?”- Z¸Ó'I›¼èÇì‘©©¾µ<©;u€û£Œ,À€ZqZK¦Ø/vœ±õ>‹]Þ²¥Sç‡8ÀñpVne#´Ò±\ZåÜZJ6^׿4M#}W:åÜä—>[‘¤þ­MÂÊŠXZUi¾þ>šËFë,“t­øw-…m¥¸•ÜóåɇK¿Ó÷´àÎUîh ¦Ó0ÕÞ•.„±3NîÕâº_ã``´P¸qêÓæš0q³+·"ÃÁOâ;…Ó„Ÿ÷×@’ûè´G_ê§t”.….÷žæAå¦-wÜâ¨.|+¯Ô÷ZôTŽZãx¸Ú0^iµQ>–üqç=mW¾å&}ÓOx']ž€ú©Â¤qNqÒòäãFáxpGpã÷Þ{¯qí$@þöáÿ5b áˆ"-@­F<”&üJá5óþ"y Èrîò#­ZÞ•‡òV=óé¤áFO¥ÑÒó×ù¦4i¶¾™ýSܦïµà„ðÕâ¤~i»*í¼[ú])n†tÒp¼§ßiØô= ƒh±bs‰y[;þT:ÆÈ’È×ÙhÒAÓUëò*üòËhÎ ù~gÞæÛåëà égXÎÐÁd&ãfö¡PçèA{ } >-0›ŸÍ\ç†â”8ÄF?ç;!¤âŽfnä¶Ô]£>ZR#oïdÓ–r9ŽðÁ&?ši:HÚ¬„Iø ÍÚƒÎý¡ê.ð¾À,ò(èø²5§D§e B@É{oh !nÀÏ­ÇøÄ¾Úùs.ß ë;E´ßPÍæ0k3÷µŽoX"Á„¬œ´‡¸Õw¯jÞÒ7„ö]¾ùP¥Æ¦x T :7Fw‚ÊÀ“õ¨ÐÊêÀÈæ]ð뎲ª|äj=šO[mµ•©*˯;ñWļ…—O>ù8Ú><×ÄWháÑ–òëŽr#% Ê!­@κѯà@tH·;Ê–æ)QDïXHáèG&ä—†÷÷ÆÇ@C%š µRÎjpP|ÔsêÞý5{Dcoų'¨Îæa¯½ö²sLÖÕÆrW•;òS6P>Σ謊OùVû;Å+}YË&T§·} iÀ¯E¢,$<p…Óåp-‡\Q³æ,žf)Ò¯q»ã¡’SnÎñ¡,AÿKqÚåò<» I”ê¥Cc³ C–‹/¾¸Ylàðã}÷Ýg^÷u‰±s®\Ž]ê®ÿ*"ž°ê€9"ˆ†{ÆCÝõEÄe=à­QÊØD‰Æ¡c§Oû(Ð?qAgu–¼×ĹìÓqÂ^¢ @ß]Q òêÊüº¢N]‘ýN}¯«ò#)¦`Y \»‚MƵÖZ«dô—ppQEïsEm™®-WÃ¥®EcësÓjIâˆ#Ž0kΘóÁ¢öÂ0?ƒYÞt²s‚Ñzœ7JŒrýs?Ø;Ä<f§0e•šÄRkx=N”º±mevût$lç °…Ç ù7ß|Ó®¡FćM;ÄÌW–ÂFsªí¨³Þ£G›tx²Y h¢â=¬øv¨ ¨}Ó¶EDG€± éÓ§$î^¤ýJnþt Ôœ( •ÊM<ùIñ 4Y£QˆhSôù‹áà ´_U€ªyÚ€Úž_¾ÑØD£”;¸PZ€3‚ƒÖ~R¹~Ô†ì=Šc [1àD©[Ñßræù‰¢ƒÅ ö¸†3'}ûöµëRs@ŠGé*»å‹¢ë•Ö)ß^pB\§ã K/½tXb‰%Bz³±â7R;»zé:N”:»œvž BŒÃu\ø†Æ7r· wóp(7…F؃bòM'ÞüwZßzx§M€VúL´mð[B=“ü±Ç>ø`ã04y+ž¾Qî@ùaðàÁ¶Ç$êÁGˆ/÷Þ{o9·é‰ètà0!Dà†=!4‡¢õ§ ^ äXX/GÄE4)DK¯MõHŽ:Ç€¥:oÀö¿%EÚL¢¬øáPAGyî‹I•+è™”¿ÿþ»heb"»:7O8¸´ü/å ÒÉ™ü°Vè ¥†vÚ©âÝ:” þwÞ¸%­<¸•‘#G†aÆ…>øÀÜN8áÛÇ!yèÉ;?4à 88G~Ô?ˆ.uDzÍ4óLa^ ØÁeü8¦[R­@¹¤¡:ê™ âŸŽÇÀ¯p¢ä]a, h¢×³œØOجׅ€\Îñ‚ÓBœE|&`q¸3±žIZ@MÔš¼yr{0ÆEQk'Ÿô|ŽâòT9Iã”SN »í¶[É›}2ˆ#Dƒ}3ÒU¹HN¢‚‚Kí„‘•ø8å Aª†•Ÿ¨N¥Âø‹cÀ1PFP«)¨j h2Õ“:3‘§“¿ü˜¼ùÍ>ûìö«„ˆÄn„DF"Ÿ6i ÜtÓMm¯1Øl³ÍfáËâãΞêÕˆìû]zé¥öÃË÷Ýwß±å†Èð#?ž­•[¸àY®|­IÓÃ:qAׯ÷¡::mÃ@Ú…Òw&jMÚmIó:ÜšzÐA™v „,øõÍY,ÔÅ?þxãjÈ‹=¬\Œ1Â{S-饖=}OÃø»cÀ1бp¢Ô±øôÔÊ` %Te¼Çq"¼‡€‡ne9ü+B¤'éôÓOÇsŒ‰àà \""piìI«pœÌ~uPøJþîîp t œ(u ž=—6`@Ä ÂƒÒZx"ÕœÐСCJ *²".¿”³jC<ŠcÀ1ÐÅp¢ÔÅ÷ìZ‡&Ð\`{Cì1!Ú;ãŒ3JRJÒˆ8'”bÅßÅÅ€¥â¶—ìW ˆ0¡ÌÀy$4éx4Èö*$G cÀ1PhÊQýÕÏKÜ€Ë0q]<W·Ýv[3bŠ·¤h`¯‚c ÁÀ˜{·Gu ‘ÝyçM©2úžQQ[ÊËåhœ(µ o«›0À9'4êàŽÆÃ€¥ÆkÓ¦¨‘+.4E3{%›N”š°Ñ½ÊŽÇ€c ¨p¢TÔ–ñr9Ž&Ä€¥<¯²cÀ1à(*œ(µe¼\ŽÇ€c  1àD© Ý«ìp 8ŠŠ'JEm/—cÀ1àhB 8QjÂF÷*;Ž¢bÀ‰RQ[ÆËÕj Èøj«#,õh”º µ^œ:À€¥:h$/bmHÔÖó¤N=ÒºÔV{åh 8QjŒvlúZpÇÈ N[IDATÒ÷ßo×®C4©s {gù¯H•@×ÀWò—»ê)¥z&¬ª?­Å€¥ÖbÌ÷Ýv›j=äCÂ7ß|>ýôÓÀû9çœcÄŠBc/‰¾Üd/w=ó•”»žø¿üòËaË-·4Ëåï¿ÿ~8üðÃûï¾kQóyÝ~ûív”ÒU:zÊ–ß#<¶Ùf+û_|aÁ ãàh 8Qj––nðz¾öÚkáí·ßn¸a˜|òÉíj ˆÄj«­&šh"«½®I%”0éKd¦§üô”»ž¸ÿö·¿ Ë/¿|˜xâ‰ÃW_}l ?åÅ;±â] \~¤ Ì3Ïø ¼óÎ;áÛo¿M½íýË/¿ o¾ùføßÿþWâ´æ˜cްõÖ[‡ 'œÐ¸°UVYÅòâÎ'ˆå±™d’IÂTSMeiÉMåùúë¯-Äj–Yf1BJ@…³HþÏ1Ð$p¢Ô$ ÝèÕdB‡W^ye8à€Lvì±ÇÁ¹è¢‹Â4ÓL6Úh£0å”S†û„’§Ÿ~:üá°Kçšk.#nˆæ7Þx£”µÖZËîqB$f¹å–3în â7lØ0#*sÎ9gXi¥• /¼`aωó¡¬gŸ}¶•gƒ 6SL1Ex衇JD¨Q´DüŸc  0àD© ¹Yª(ÎñW¥ïºë®a—]v wÜqGØm·Ý‹/¾î½÷^ûõë×/¼þúë†Änë®»n€8}öÙgaá…—_~¹ùÁ‘Þõ×_ž|òI»†}‡v0Ž é‰'ž0.‰wöआ>ú裰Æka‚XN:é¤%¥®r?ꨣÂ+¯¼bÄñÎ;ï41ào¼Ñ,Måõt TÄ€¥Š¨qzÅÀÔSOf˜a†0ãŒ3Ú¾å˜cŽ =zô°*Í?ÿüQÛÍ7ßlßC† {ï½·ÅAKnºé¦3âG#í:öŒð[{íµÃ¨Q£¢;q>"†$ö׿þ5Ì;ï¼–÷Ž;îhÄ ‘ âE‰áä š¤AÜX ôíÛ7ÜrË-Vÿçhf LØÌ•÷º7.D0 $p1^x¡í3!C1á7¿ùM‰HL6Ùdáä“O¶=%Î\:è ûA`FŽ]tѰâŠ+†õ×_ßžÒ˜‹¼#²CD(@¤·Â +˜þ|CäàšÈ΋ò°ß!…p)‘SZþt 4 œ(5KK7Y=™Øát Hp9p-ì ñq@Ì&޵nDv›o¾yXh¡…LäöÔSOq€ˆ@XÁADø!ú{üñÇ-¾ÐJ~pD"†¸ãvÿý÷F~& ”gÀ€VʈØPŠJÓŸŽfÄ€‹ïš±Õ› ÎˆÊ Jâ:ö“Pp@dQ:ì°ÃŒKAœ=öž_|q㢞}öY‹ qÚ}÷ÝíìSŸ>}ì,¢¶?þØžP)ÑDKðÌ3ÏØk(6„@‰³B\‡’Dˆò@”Ž8∀† rÛ‡ÿs 4œSj²o–êÂ!ŠPÛFEžÛo¿}øÓŸþdê׈͖]vY×ágÃAXö}¶Új«Ð³gÏpÓM7Y\8*”ДëÝ»·*Ò‡ˆ Rœ{î¹áÕW_5îhÏ=÷ W\q…‰æà„8Ð  (ѫ׳Uœsâ›2¢ùçàhv 8QjöÐ õ‡·B• âLfuÖðÀ˜¦*Ú(°7ÄÞ¿#FÔ¾á^6Ûl3;ÀŠ"Ä{ï½Ydã–ÐÚ#."·£>:Ì>ûìóE ö§øF|w…ºù[ñ<\ñT¿„}ýõ×L ö­êœzê©á“O>1±œÜôT\}ëYÉ]þ<+…©äžÆÕ{­a!¢$ñÎ6ÛlVŸé§Ÿ¾b”¾?„甩5›¸.p<œ7b¿ˆý!Äršä!f)aàÀ¨æ—›†'?‰Þ Ÿ¦Kx¥¡÷4 ½+Ç{,wÜq8;8šN”š²Ù¯ÒˆÛPX@݈8T{oÉ/ïŸ~§(}' P)ÿj~œ­b‰sSXzpp 4œ(5[‹7h}{D 7~)¤D!u/â;e…[ê+ø¥POõHËí`À‰R[°æq ‡&tA½Nâ"Lõ^•ßŸŽ¶`À‰R[°æq ‡z%DyD6J=òõòoÇ@­ðóµbÊÃ9ŽÇ@§cÀ‰R§£Ø3èH HL§gG¦íi9Ý'JÝß^‚0 ±U1ËãLk@šq Ô!üðl6Z3Ž‚„™®šÀTÐþó3 „Y®?wp 8Î)5N[6tMà°#7hÐ 3ϳ×^{™ùŸ†®´WÎ1Єp¢Ô„^OU†K‚[‚(qÝÀS€ õß_24ø?Ç@C`À‰RC4csTkÞ\º‡øîïÿ»]ûÐ5÷Z:šN”š§­ë¶¦RrÀ8éhõXsÍ5Íœöíä_·ô‚;% 8Q*¡Â_ŠŒ]CÁ…}òN þÏ1Ð0pí»†iÊæ¨Èÿýßÿ™&w98‡'JצMQ#©Š7Ee½’Ž&€‹ïš¨±ÛSÕ¢h¸QŽ” ¥\íÁ­Çu 8Æ`À‰Ò\ø[ eï†r¤eIß«¿®½~þùçº.¿Þ1Ð 8Qj ¶º)¬¸q *†¾åŸºó^É¿?…Ñó»ï¾ -MŽmÉ/_våǹ´úé§@¹FáË…•_úä(^n£CŒþŸæ“ù·RP…SúNã”Çù§áåöÌ3Ï„“N:)°—–ÆWØ4w 4œ(ÕA+Š—  KßòOÝ©Vê/?U7õÃ-õWzz~ûí·auÖ ü±E—&œÒRÜ4M¹éYÎøÊCiåÝäŸÆWþO=õTØyçK¶ÔÃÓ°Ê?MWiÊ/ ¯rÈMaÒørS{†ÑW«§áRÿ|º|§é(žâdÙ/œŸþù,PžŽFÀ¥‚·(ÜÉ?ü`¥5jTøâ‹/J9«ç÷ß?|óÍ7æÏ$ÅĬð¸ôÑGöŸÀóᇆ¯¾úª——üÑ~L˜Lˆ¤G:wÜqGøòË/Ç kñŸÒ¦lÄaÅ4äG>ä÷ý÷ß—ÜðÏs`Æý|ÿ%MÞ„¾þúëðßÿþ×¾eŒõÿû_xì±ÇJåÂ4±“GXp§üI—ºøSù‘6x„ø (áwüÁ›Üø~ï½÷å ¬ÊL9Èü ǸŸO?ýÔ‚’NÚ¾”Cøü ,ÌDMæ›o>%mySêGpp 4â@q( âde¥zþùç³=÷Ü3»é¦›e·Þz«¹1¾—^zi{F¢aîo½õ–…?묳²•W^9›e–Y²UVY%{á…Jµ|üñdz^½ze}ûöµ¸çw^ œùßvÛmÙA”vØaÙ +¬E¨öMÞ3Í4SvÏ=÷X8•8IfäG˜ž={fÑHjöæ›oZ¸8q—üÈ/N°Ù£>j~‘ˆeë­·^öòË/Û7ÿzè¡l§v²ï8ágÛm·]FùþøÇ?fsÏ=w¶ÖZkeqâÎÀ ùñÛ|óÍÍíóÏ?ÏöÛo¿,š!ʦvÚìÏþs ¡¥EžÿøÇ?²ë®»Îâ<øàƒæ~á…Ú÷’K.iOò®¾úêlË-·,áåþûïÏâÝì“O>1á±Å³x‡~x)ìi§–x≆ÃßýîwÙRK-•92;úè£í2_tÑE–ÎK/½”E;~Ùgœ‘-¿üòÙo~3©áïõ×_7ÿ»îº+8p`®Ú<.±Ä–ï¹çžkîü‹„±ôî/ŽzÅ+:‡b@“þsÏ=g“Ïî»ïžEqUÆ$ÏÄÉÄÆWýF(ø†€Ä¿ù­¶ÚjÙÓO?}ðÁ6â9ûæý‚ .° ûÉ'Ÿ´ð×\sa!Zâ¶o&É·ß~;‹ÜBÆÄIœx 4ñX“ॗ^šõèÑ#{öÙg-ýÝvÛÍÂSV&câ’‚ɘoÊIyxfƒJ-pçwf °oˆþIêaV²“O>9‹œOvÙe—e½î# Z{ÈöÞ{ïŒxä·f[l±…ù©ž&Ê9¡ BNúqß&‹ÜŽ|¾ßyç,r;Yÿþý³‹/¾8‹IÏEY]H ±@ˆ\Åçû‘G±¼Ž;î8ó‡FN)ÛgŸ}ì›…Dmذaö¹µìµ×^³÷M7ÝÔððî»ïa…@_pÞ/–\’ùÐF”—zÌ:ë¬Ùõ×_oùª=ìÃÿ9êN” Úp"JLØLDZÁS\&^&>““&œ“µ&òo¼±T3VÙ¤ñÊ+¯d¬ø£ ¹’/p9pLô‘e–Y¦Dpð‡‹"¾¸• ?ÞÉÎBEKÙðáÃðD£©YÜ‘—=×^{íì†n°üH÷Å_,ùÉÁi"°LÔ‚sÎ9;Ûc=ìóᇶº€Â“8ß•W_}ÕÜRÎ Â.Øzë­³sÎ9§„Gƪ«®šEÅ „Úh£²!C†X]ñ€#ƒSÀéÁR'€°û¼³Ûo¿=‹6û²(Æ37ðCYi*·"€gܨ?u„㥠¢•t+õ¡Ýi/ÚŽò98ÆÎïP` °ž‚,Ä ×.¸‹\‚íg°ß3ñÄÛþ{ø÷îÝ;Ì0à ¥Zq)^$M.Âc؈%L0ÁÓ=ƒ6…Ò˜gžylï"®¼-/íë°Ï&{Æ Ôöc”ùÏ<óÌfÁ›=’È‘…(~´xÔ…²`T•´HÐSïú&€}ÁÄObe曽ÊFž‘ XK.¹$ð(gS–ö‚Yd‘Å™æ'uÃ[ä„B$0V÷I&™Äêeâ?â¢H±í¶Û†¡C‡.(ÛTSMe÷:E‘íOEâøK€z‚²ÏůG%eÕ‹òýüËÏVŽi¦™ÆâòrDb¢ÔêÎH+rh!ŠõùRoÂEn6,¸à‚†ÏI'´”†¿8êN”ê å&Ÿ|òÒÄÌ‚ÃV[m6ÞxcÛ°Ç-®ºK™¨£XÇžª“%ÚtÓMgDA R€x@Hô­É•I»¾ã">ºŽöc"$&b@ïqo+L1Å6¹R6@éRFÒTzÄ0㟂&qÜx×7ñI“'éÍ6Ûla›m¶±ºPÜ"7dîOˆ éLè( à÷lì]xœrÊ)- J ·Ür‹½GŽÅðMšÿú׿Bä&Ãé§Ÿ"‡âþUØe—]J8 _@y…¹é9þxã[}Sò@³v§­‰Où­¿þúa×]w57ê‚?‹ú88®}WðVd"ʯ€£2­˜!2qó߈MÜ2­.¸& î'•jÅK¦¥ÆŠ.(îiwCÚ@/…¨@&›l2ã:&ždtJ@D@ÄFq™áÌþýï+¸]ÂwÇd÷J\&VˆcT0Ž î«”â2áO=õÔ¥o^”ïLØ"nLüà¸/ˆ`­WÙ#r&•SO=Õ¸â)p§W!Fœ ‚›Ž?þø÷vŒ“Úd“MìÊ Ü£2HˆÊ!*dX¾ê¨v¢<ù¼ ª‡žœmÒ;Üš€«9Ê„??҃åLÔ³G¬D˜¶ƒ`Fí¤tüé¨K ÄŽìP@ °WÄÉÞöØ+°'Ö]œ(Mqí®z-EŽÇöVК‹Ñ6þÑÎâýØcµ=6øÙìÇíòË/ÏP à]û:( ­D¢aO6äQ08æ˜clÏJ~òGQ€4=ôÐ’¦sZdø¡ü@Ú¼pÀ¶'sSFÀíÊ+¯´½Þ© …”‘;É6Û|3ûdˆðlôG^IC‘ºžrÊ)æÇžÀ^aÙ(ý(žËÐÂCkí>0¤]‡"€âÇä“Oa8–¢ e!\äZ³…^8‹Ü’ù|ðÁÙþûï_Úƒ’òJ)€öýØ›BÑa¡…²²¡ÁG>”“½"€ý(¾i[öɶßþÿÛ9›ãb ëLpI”ÁP'N9Ppõ¤ rÏû^æeCHrËN¬vmýØZ-Ø–%óè,Hô¥ -ñ­¼ ŽË°ÀL-0þU¿ê¿ú>yõËV›e¯ŒY‰O EéÂŽ)=¸ /â œ;¢AÑq<M2^eg%Ïv2ÅJI^COÌJƒ¶·ñ<:">´ÛíJéÓW=ÂÃvg™”pPÊü+M”×-% ¦#Áóà³X,,zy¹Ôùéìç@N)ÔŽ—à%wzV åAºd{J²cDÐñPN§S)Ã^ ^z*YÂϰÝnk½^{ËŽ3=<^f¼I =쨤†ÒD_Jt°Ç¨ŒCß—Ë¥õÄ{£[­V¶³&&{)xYJܰ‡y<k¿ß{Û˜¼x0œcâl:ãmò\Ä 4‘¹ßÃáPJÁ·~xLØ]àE–zSGÞ›RÚýØl6×wgEÇeX`æ“Ò~™€¦*v<[`li˜tö§”zíA/É Ð‘(ÞN/›xãò[žïú£‹[ºÜèúªëÒËaì¸^{ÇOí>x€è<÷.ßñ÷ÊS&!¶8u~ÊO×cÊÛë½|¯¿A˜›ÞG³¹iþôe dða ê<¸LH‡u’ˆEÐF±È¦NÓro :ÐyÞ0¯Ðiû©ÿ”Fß½ÿ^¦ úG»^þJÈE†{× ;Âyú  Oø‚C6´”¹z;à¨ç9¢k!¨ï³º½_h©ßë¾Ãs¶À+Œ)ôè:8íIEND®B`‚cbmc-cbmc-5.6/doc/html-manual/counter.c000066400000000000000000000003541301406513700200030ustar00rootroot00000000000000void next_timeframe(); struct module_top { unsigned int counter; }; extern const struct module_top top; int main() { next_timeframe(); next_timeframe(); assert(top.counter==2); next_timeframe(); assert(top.counter==3); } cbmc-cbmc-5.6/doc/html-manual/counter.v000066400000000000000000000001761301406513700200300ustar00rootroot00000000000000module top(input clk); reg [3:0] counter; initial counter=0; always @(posedge clk) counter=counter+1; endmodule cbmc-cbmc-5.6/doc/html-manual/cover.shtml000066400000000000000000000230251301406513700203470ustar00rootroot00000000000000

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 --trace --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 trace (if there exists) of the program execution that satisfies such a goal is printed out in XML format, as the parameters --trace --xml-ui are given. Multiple coverage goals can share a trace, when the corresponding execution of the program satisfies all these goals at the same time. Each trace corresponds to a test case.

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".

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.

cbmc-cbmc-5.6/doc/html-manual/cprover-source.shtml000066400000000000000000000640651301406513700222200ustar00rootroot00000000000000

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 subt;
  typedef std::map 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. 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. 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.
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_typet Boolean type
symbol_typet Symbol type. Has edge "identifier" to a string value, which can be accessed with get_identifier and set_identifier.
struct_typet, union_typet Represent a struct, resp. union types. Convenience functions to access components components().
code_typet The type of a function/procedure. Convenience functions to access arguments() and return_type().
array_typet Convenience function size() to access size of the array.
pointer_typet Pointer type, subtype stores the type of the object pointed to.
reference_typet Represents a reference type, subtype stores the type of the object referenced to.
bv_typet Represents a bit vector type with variable width.
fixed_bv_typet Represents a bit vector that encodes a fixed-point number.
floatbv_typet Represents a bit vector that encodes a floating-point number.
string_typet Represents 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
transt Represents an SMV-style transition system with invariants invar(), initial state init() and transition function trans().
true_exprt Boolean constant true expression.
false_exprt Boolean constant false expression.
symbol_exprt Represents a symbol (e.g., a variable occurrence), convenience function for manipulating "identifier"-edge set_identifier and get_identifier
predicate_exprt Convenience constructors to create expressions of type "bool".
binary_relation_exprt : predicate_exprt Convenience functions to create and manipulate binary expressions of type "bool".
equality_exprt : binary_relation_exprt Convenience functions to create and manipulate equality expressions such as "a == b".
ieee_float_equal_exprt : binary_relation_exprt Convenience functions to create and manipulate equality expressions between floating-point numbers.
index_exprt Represents an array access expression such as "a[i]". Convenience functions array() and index() for accessing the array expressions and indexing expression.
typecast_exprt Represents a cast to the type of the expression.
and_exprt, implies_exprt, or_exprt, not_exprt Representations of logical operators with convenience constructors.
address_of_exprt Representation of a C-style &a address-of operation. Convenience function object() for accessing operand.
dereference_exprt Representation of a C-style *a pointer-dereference operation. Convenience function object() for accessing operand.
if_exprt Representation of a conditional expresion, with convenience functions cond(), true_case() and false_case() for accessing operands.
member_exprt Represents a some_struct.some_field member access.
codet Represents 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 &symb);

                                 // 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:

GOTO Represents 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.
ASSUME An assumption statement that restricts viable paths reaching the instruction location to the ones that make the expression guard evaluate to true.
ASSERT An assertion whose guard is checked for validity when the instruction is reached.
RETURN A return statement in a function.
END_FUNCTION Denotes the end of a function.
ASSIGN A variable assignment.
SKIP No operation.
OTHER Any 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 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;
  };

}
cbmc-cbmc-5.6/doc/html-manual/expr.c000066400000000000000000000001211301406513700172720ustar00rootroot00000000000000int *ptr; int main(void) { if (ptr) *ptr = 0; if (!ptr) *ptr = 1; } cbmc-cbmc-5.6/doc/html-manual/expr.svg000066400000000000000000000417331301406513700176650ustar00rootroot00000000000000 cbmc-cbmc-5.6/doc/html-manual/file1.c000066400000000000000000000001221301406513700173150ustar00rootroot00000000000000int puts(const char *s) { } int main(int argc, char **argv) { puts(argv[2]); } cbmc-cbmc-5.6/doc/html-manual/file2.c000066400000000000000000000001441301406513700173220ustar00rootroot00000000000000int array[10]; int sum() { unsigned i, sum; sum=0; for(i=0; i<10; i++) sum+=array[i]; } cbmc-cbmc-5.6/doc/html-manual/footer.inc000066400000000000000000000000731301406513700201470ustar00rootroot00000000000000 cbmc-cbmc-5.6/doc/html-manual/gcc-wrap.c000066400000000000000000000044161301406513700200320ustar00rootroot00000000000000const char gcc[]="gcc"; #include #include #include #include #include #include #include void run(const char *what, char *const argv[]) { pid_t childpid; /* variable to store the child's pid */ int retval; /* child process: user-provided return code */ /* now create new process */ childpid = fork(); if(childpid>=0) /* fork succeeded */ { if(childpid==0) /* fork() returns 0 to the child process */ { execvp(what, argv); /* usually no return */ fprintf(stderr, "execp %s failed\n", what); exit(1); } else /* fork() returns new pid to the parent process */ { int status; /* parent process: child's exit status */ wait(&status); /* wait for child to exit, and store its status */ int code=WEXITSTATUS(status); if(code!=0) exit(code); } } else /* fork returns -1 on failure */ { perror("fork failed"); /* display error message */ exit(1); } } int main(int argc, char * argv[]) { // First do original call. // on some systems, gcc gets confused if it is not argument 0 // (which normally contains the path to the executable being called). argv[0]=strdup(gcc); run(gcc, argv); // now do preprocessing call char **new_argv=malloc(sizeof(char *)*(argc+1)); _Bool compile=0; _Bool assemble=0; _Bool next_is_o=0; unsigned i; for(i=0; i

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. 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. 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.

cbmc-cbmc-5.6/doc/html-manual/goto-cc-linux.shtml000066400000000000000000000056041301406513700217240ustar00rootroot00000000000000

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. Download the Kernel sources at http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.tar.bz2 .

  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 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.

cbmc-cbmc-5.6/doc/html-manual/goto-cc-rockbox.shtml000066400000000000000000000051061301406513700222310ustar00rootroot00000000000000

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. 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. Now download gcc-wrap.c:

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

  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. 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. 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. 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.

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

cbmc-cbmc-5.6/doc/html-manual/goto-cc-variants.shtml000066400000000000000000000031661301406513700224150ustar00rootroot00000000000000

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-cc gcc (control-flow graph only) gcc -E
goto-gcc gcc ("hybrid" executable) gcc -E
goto-armcc ARM RVDS armcc -E
goto-cl Visual Studio cl /E
goto-cw Freescale CodeWarrior mwcceppc

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.

cbmc-cbmc-5.6/doc/html-manual/goto-cc-visual-studio.shtml000066400000000000000000000031451301406513700233730ustar00rootroot00000000000000

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. Add a configuration for the goto-cc build for your project in the configuration manager, named "goto-cc".

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

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

  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.

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

cbmc-cbmc-5.6/doc/html-manual/goto-cc.shtml000066400000000000000000000120061301406513700205610ustar00rootroot00000000000000

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. Unpack the sources by running tar xfz wu-ftpd-current.tar.gz

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

  4. Configure the project for verification by running

    ./configure YACC=byacc CC=goto-cc --host=none-none-none
  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. Run a model-checker, e.g., CBMC, on the model file:

    cbmc src/ftpd

    CBMC automatically recognizes that the file is a goto binary.

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.

cbmc-cbmc-5.6/doc/html-manual/goto_program.svg000066400000000000000000002445201301406513700214050ustar00rootroot00000000000000 cbmc-cbmc-5.6/doc/html-manual/header.inc000066400000000000000000000010601301406513700200760ustar00rootroot00000000000000 CPROVER Manual
cbmc-cbmc-5.6/doc/html-manual/highlight/000077500000000000000000000000001301406513700201255ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/html-manual/highlight/CHANGES.md000066400000000000000000001434321301406513700215260ustar00rootroot00000000000000## 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][] - *Darkula* by [Jet Brains][] - *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
cbmc-cbmc-5.6/doc/html-manual/highlight/LICENSE000066400000000000000000000027321301406513700211360ustar00rootroot00000000000000Copyright (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.
cbmc-cbmc-5.6/doc/html-manual/highlight/README.md000066400000000000000000000106411301406513700214060ustar00rootroot00000000000000# 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. **Note:** the library is not supposed to work straight from the source on GitHub; it requires building. If none of the pre-packaged options work for you refer to the [building documentation][6]. Also, if you are using something like almond, you need to use the optimizer to give the module a name. The basic example would be: ``` 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.org/en/latest/api.html#inithighlightingonload [2]: http://highlightjs.readthedocs.org/en/latest/css-classes-reference.html [3]: http://highlightjs.readthedocs.org/en/latest/api.html#highlightblock-block [4]: http://highlightjs.readthedocs.org/en/latest/api.html#configure-options [5]: https://highlightjs.org/download/ [6]: http://highlightjs.readthedocs.org/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 cbmc-cbmc-5.6/doc/html-manual/highlight/README.ru.md000066400000000000000000000126651301406513700220430ustar00rootroot00000000000000# Highlight.js Highlight.js — Ñто инÑтрумент Ð´Ð»Ñ Ð¿Ð¾Ð´Ñветки ÑинтакÑиÑа, напиÑанный на JavaScript. Он работает и в браузере, и на Ñервере. Он работает Ñ Ð¿Ñ€Ð°ÐºÑ‚Ð¸Ñ‡ÐµÑки любой HTML разметкой, не завиÑит от каких-либо фреймворков и умеет автоматичеÑки определÑть Ñзык. ## Ðачало работы Минимум, что нужно Ñделать Ð´Ð»Ñ Ð¸ÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ highlight.js на веб-Ñтранице — Ñто подключить библиотеку, CSS-Ñтили и вызывать [`initHighlightingOnLoad`][1]: ```html ``` Библиотека найдёт и раÑкраÑит код внутри тегов `
`, попытавшиÑÑŒ
автоматичеÑки определить Ñзык. Когда автоопределение не Ñрабатывает, можно Ñвно
указать Ñзык в атрибуте class:

```html
...
``` СпиÑок поддерживаемых клаÑÑов Ñзыков доÑтупен в [Ñправочнике по клаÑÑам][8]. КлаÑÑ Ñ‚Ð°ÐºÐ¶Ðµ можно предварить префикÑами `language-` или `lang-`. Чтобы отключить подÑветку Ð´Ð»Ñ ÐºÐ°ÐºÐ¾Ð³Ð¾-то блока, иÑпользуйте клаÑÑ `nohighlight`: ```html
...
``` ## Ð˜Ð½Ð¸Ñ†Ð¸Ð°Ð»Ð¸Ð·Ð°Ñ†Ð¸Ñ Ð²Ñ€ÑƒÑ‡Ð½ÑƒÑŽ Чтобы иметь чуть больше ÐºÐ¾Ð½Ñ‚Ñ€Ð¾Ð»Ñ Ð·Ð° инициализацией подÑветки, вы можете иÑпользовать функции [`highlightBlock`][2] и [`configure`][3]. Таким образом можно управлÑть тем, *что* и *когда* подÑвечивать. Вот пример инициализации, Ñквивалентной вызову [`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`][3]. ## 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 хоÑтинга или Ñкачать индивидуальную Ñборку, а также уÑтановив модуль на Ñервере. Ðа [Ñтранице загрузки][4] подробно опиÑаны вÑе варианты. Обратите внимание, что библиотека не предназначена Ð´Ð»Ñ Ð¸ÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ Ð² виде иÑходного кода на GitHub, а требует отдельной Ñборки. ЕÑли вам не подходит ни один из готовых вариантов, читайте [документацию по Ñборке][5]. ## Ð›Ð¸Ñ†ÐµÐ½Ð·Ð¸Ñ Highlight.js раÑпроÑтранÑетÑÑ Ð¿Ð¾Ð´ лицензией BSD. Подробнее читайте файл [LICENSE][10]. ## СÑылки Официальный Ñайт билиотеки раÑположен по адреÑу . Более Ð¿Ð¾Ð´Ñ€Ð¾Ð±Ð½Ð°Ñ Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð¿Ð¾ API и другим темам раÑположена на . Ðвторы и контрибьюторы перечиÑлены в файле [AUTHORS.ru.txt][9] file. [1]: http://highlightjs.readthedocs.org/en/latest/api.html#inithighlightingonload [2]: http://highlightjs.readthedocs.org/en/latest/api.html#highlightblock-block [3]: http://highlightjs.readthedocs.org/en/latest/api.html#configure-options [4]: https://highlightjs.org/download/ [5]: http://highlightjs.readthedocs.org/en/latest/building-testing.html [8]: http://highlightjs.readthedocs.org/en/latest/css-classes-reference.html [9]: https://github.com/isagalaev/highlight.js/blob/master/AUTHORS.ru.txt [10]: https://github.com/isagalaev/highlight.js/blob/master/LICENSE cbmc-cbmc-5.6/doc/html-manual/highlight/highlight.pack.js000066400000000000000000000427071301406513700233610ustar00rootroot00000000000000/*! highlight.js v9.4.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(/&/gm,"&").replace(//gm,">")}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/^(no-?highlight|plain|text)$/i.test(e)}function i(e){var n,t,r,i=e.className+" ";if(i+=e.parentNode?e.parentNode.className:"",t=/\blang(?:uage)?-([\w-]+)\b/i.exec(i))return w(t[1])?t[1]:"no-highlight";for(i=i.split(/\s+/),n=0,r=i.length;r>n;n++)if(w(i[n])||a(i[n]))return i[n]}function o(e,n){var t,r={};for(t in e)r[t]=e[t];if(n)for(t in n)r[t]=n[t];return r}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){f+=""}function c(e){("start"==e.event?o:u)(e.node)}for(var s=0,f="",l=[];e.length||r.length;){var g=i();if(f+=n(a.substr(s,g[0].offset-s)),s=g[0].offset,g==e){l.reverse().forEach(u);do c(g.splice(0,1)[0]),g=i();while(g==e&&g.length&&g[0].offset==s);l.reverse().forEach(o)}else"start"==g[0].event?l.push(g[0].node):l.pop(),c(g.splice(0,1)[0])}return f+n(a.substr(s))}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 u={},c=function(n,t){e.cI&&(t=t.toLowerCase()),t.split(" ").forEach(function(e){var t=e.split("|");u[t[0]]=[n,t[1]?Number(t[1]):1]})};"string"==typeof a.k?c("keyword",a.k):Object.keys(a.k).forEach(function(e){c(e,a.k[e])}),a.k=u}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)),void 0===a.r&&(a.r=1),a.c||(a.c=[]);var s=[];a.c.forEach(function(e){e.v?e.v.forEach(function(n){s.push(o(e,n))}):s.push("self"==e?a:e)}),a.c=s,a.c.forEach(function(e){r(e,a)}),a.starts&&r(a.starts,i);var f=a.c.map(function(e){return e.bK?"\\.?("+e.b+")\\.?":e.b}).concat([a.tE,a.i]).map(n).filter(Boolean);a.t=f.length?t(f.join("|"),!0):{exec:function(){return null}}}}r(e)}function f(e,t,a,i){function o(e,n){for(var t=0;t";return i+=e+'">',i+n+o}function h(){if(!k.k)return n(M);var e="",t=0;k.lR.lastIndex=0;for(var r=k.lR.exec(M);r;){e+=n(M.substr(t,r.index-t));var a=g(k,r);a?(B+=a[1],e+=p(a[0],n(r[0]))):e+=n(r[0]),t=k.lR.lastIndex,r=k.lR.exec(M)}return e+n(M.substr(t))}function d(){var e="string"==typeof k.sL;if(e&&!R[k.sL])return n(M);var t=e?f(k.sL,M,!0,y[k.sL]):l(M,k.sL.length?k.sL:void 0);return k.r>0&&(B+=t.r),e&&(y[k.sL]=t.top),p(t.language,t.value,!1,!0)}function b(){L+=void 0!==k.sL?d():h(),M=""}function v(e,n){L+=e.cN?p(e.cN,"",!0):"",k=Object.create(e,{parent:{value:k}})}function m(e,n){if(M+=e,void 0===n)return b(),0;var t=o(n,k);if(t)return t.skip?M+=n:(t.eB&&(M+=n),b(),t.rB||t.eB||(M=n)),v(t,n),t.rB?0:n.length;var r=u(k,n);if(r){var a=k;a.skip?M+=n:(a.rE||a.eE||(M+=n),b(),a.eE&&(M=n));do k.cN&&(L+=""),k.skip||(B+=k.r),k=k.parent;while(k!=r.parent);return r.starts&&v(r.starts,""),a.rE?0:n.length}if(c(n,k))throw new Error('Illegal lexeme "'+n+'" for mode "'+(k.cN||"")+'"');return M+=n,n.length||1}var N=w(e);if(!N)throw new Error('Unknown language: "'+e+'"');s(N);var x,k=i||N,y={},L="";for(x=k;x!=N;x=x.parent)x.cN&&(L=p(x.cN,"",!0)+L);var M="",B=0;try{for(var C,j,I=0;;){if(k.t.lastIndex=I,C=k.t.exec(t),!C)break;j=m(t.substr(I,C.index-I),C[0]),I=C.index+j}for(m(t.substr(I)),x=k;x.parent;x=x.parent)x.cN&&(L+="");return{r:B,value:L,language:e,top:k}}catch(O){if(-1!=O.message.indexOf("Illegal"))return{r:0,value:n(t)};throw O}}function l(e,t){t=t||E.languages||Object.keys(R);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 g(e){return E.tabReplace&&(e=e.replace(/^((<[^>]+>|\t)+)/gm,function(e,n){return n.replace(/\t/g,E.tabReplace)})),E.useBR&&(e=e.replace(/\n/g,"
")),e}function p(e,n,t){var r=n?x[n]:t,a=[e.trim()];return e.match(/\bhljs\b/)||a.push("hljs"),-1===e.indexOf(r)&&a.push(r),a.join(" ").trim()}function h(e){var n=i(e);if(!a(n)){var t;E.useBR?(t=document.createElementNS("http://www.w3.org/1999/xhtml","div"),t.innerHTML=e.innerHTML.replace(/\n/g,"").replace(//g,"\n")):t=e;var r=t.textContent,o=n?f(n,r,!0):l(r),s=u(t);if(s.length){var h=document.createElementNS("http://www.w3.org/1999/xhtml","div");h.innerHTML=o.value,o.value=c(s,u(h),r)}o.value=g(o.value),e.innerHTML=o.value,e.className=p(e.className,n,o.language),e.result={language:o.language,re:o.r},o.second_best&&(e.second_best={language:o.second_best.language,re:o.second_best.r})}}function d(e){E=o(E,e)}function b(){if(!b.called){b.called=!0;var e=document.querySelectorAll("pre code");Array.prototype.forEach.call(e,h)}}function v(){addEventListener("DOMContentLoaded",b,!1),addEventListener("load",b,!1)}function m(n,t){var r=R[n]=t(e);r.aliases&&r.aliases.forEach(function(e){x[e]=n})}function N(){return Object.keys(R)}function w(e){return e=(e||"").toLowerCase(),R[e]||R[x[e]]}var E={classPrefix:"hljs-",tabReplace:null,useBR:!1,languages:void 0},R={},x={};return e.highlight=f,e.highlightAuto=l,e.fixMarkup=g,e.highlightBlock=h,e.configure=d,e.initHighlighting=b,e.initHighlightingOnLoad=v,e.registerLanguage=m,e.listLanguages=N,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|like)\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("json",function(e){var i={literal:"true false null"},n=[e.QSM,e.CNM],r={e:",",eW:!0,eE:!0,c:n,k:i},t={b:"{",e:"}",c:[{cN:"attr",b:/"/,e:/"/,c:[e.BE],i:"\\n"},e.inherit(r,{b:/:/})],i:"\\S"},c={b:"\\[",e:"\\]",c:[e.inherit(r)],i:"\\S"};return n.splice(n.length,0,t,c),{c:n,k:i,i:"\\S"}});hljs.registerLanguage("java",function(e){var t=e.UIR+"(<"+e.UIR+"(\\s*,\\s*"+e.UIR+")*>)?",a="false synchronized int abstract float private char boolean static null if const for true while long strictfp finally protected import native final void enum else break transient catch instanceof byte super volatile case assert short package default double public try this switch continue throws protected public private module requires exports",r="\\b(0[bB]([01]+[01_]+[01]+|[01]+)|0[xX]([a-fA-F0-9]+[a-fA-F0-9_]+[a-fA-F0-9]+|[a-fA-F0-9]+)|(([\\d]+[\\d_]+[\\d]+|[\\d]+)(\\.([\\d]+[\\d_]+[\\d]+|[\\d]+))?|\\.([\\d]+[\\d_]+[\\d]+|[\\d]+))([eE][-+]?\\d+)?)[lLfF]?",s={cN:"number",b:r,r:0};return{aliases:["jsp"],k:a,i:/<\/|#/,c:[e.C("/\\*\\*","\\*/",{r:0,c:[{b:/\w+@/,r:0},{cN:"doctag",b:"@[A-Za-z]+"}]}),e.CLCM,e.CBCM,e.ASM,e.QSM,{cN:"class",bK:"class interface",e:/[{;=]/,eE:!0,k:"class interface",i:/[:"\[\]]/,c:[{bK:"extends implements"},e.UTM]},{bK:"new throw return else",r:0},{cN:"function",b:"("+t+"\\s+)+"+e.UIR+"\\s*\\(",rB:!0,e:/[{;=]/,eE:!0,k:a,c:[{b:e.UIR+"\\s*\\(",rB:!0,r:0,c:[e.UTM]},{cN:"params",b:/\(/,e:/\)/,k:a,r:0,c:[e.ASM,e.QSM,e.CNM,e.CBCM]},e.CLCM,e.CBCM]},s,{cN:"meta",b:"@[A-Za-z]+"}]}});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("bash",function(e){var t={cN:"variable",v:[{b:/\$[\w\d#@][\w\d_]*/},{b:/\$\{(.*?)}/}]},s={cN:"string",b:/"/,e:/"/,c:[e.BE,t,{cN:"variable",b:/\$\(/,e:/\)/,c:[e.BE]}]},a={cN:"string",b:/'/,e:/'/};return{aliases:["sh","zsh"],l:/-?[a-z\.]+/,k:{keyword:"if then else elif fi for while in do done case esac function",literal:"true false",built_in:"break cd continue eval exec exit export getopts hash pwd readonly return shift test times trap umask unset alias bind builtin caller command declare echo enable help let local logout mapfile printf read readarray source type typeset ulimit unalias set shopt autoload bg bindkey bye cap chdir clone comparguments compcall compctl compdescribe compfiles compgroups compquote comptags comptry compvalues dirs disable disown echotc echoti emulate fc fg float functions getcap getln history integer jobs kill limit log noglob popd print pushd pushln rehash sched setcap setopt stat suspend ttyctl unfunction unhash unlimit unsetopt vared wait whence where which zcompile zformat zftp zle zmodload zparseopts zprof zpty zregexparse zsocket zstyle ztcp",_:"-ne -eq -lt -gt -f -d -e -s -l -a"},c:[{cN:"meta",b:/^#![^\n]+sh\s*$/,r:10},{cN:"function",b:/\w[\w\d_]*\s*\(\s*\)\s*\{/,rB:!0,c:[e.inherit(e.TM,{b:/\w[\w\d_]*/})],r:0},e.HCM,s,a,t]}});hljs.registerLanguage("cpp",function(t){var e={cN:"keyword",b:"\\b[a-z\\d_]*_t\\b"},r={cN:"string",v:[t.inherit(t.QSM,{b:'((u8?|U)|L)?"'}),{b:'(u8?|U)?R"',e:'"',c:[t.BE]},{b:"'\\\\?.",e:"'",i:"."}]},s={cN:"number",v:[{b:"\\b(\\d+(\\.\\d*)?|\\.\\d+)(u|U|l|L|ul|UL|f|F)"},{b:t.CNR}],r:0},i={cN:"meta",b:/#[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:"<",e:">",i:"\\n"},t.CLCM,t.CBCM]},a=t.IR+"\\s*\\(",c={keyword:"int float while private char catch export virtual operator sizeof dynamic_cast|10 typedef const_cast|10 const struct 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 class 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",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]}]),exports:{preprocessor:i,strings:r,k:c}}});cbmc-cbmc-5.6/doc/html-manual/highlight/styles/000077500000000000000000000000001301406513700214505ustar00rootroot00000000000000cbmc-cbmc-5.6/doc/html-manual/highlight/styles/agate.css000066400000000000000000000023741301406513700232510ustar00rootroot00000000000000/*! * 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/androidstudio.css000066400000000000000000000014061301406513700250330ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/arduino-light.css000066400000000000000000000020361301406513700247310ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/arta.css000066400000000000000000000015241301406513700231130ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/ascetic.css000066400000000000000000000011171301406513700235750ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-cave-dark.css000066400000000000000000000023721301406513700254460ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-cave-light.css000066400000000000000000000024231301406513700256310ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-dune-dark.css000066400000000000000000000021061301406513700254560ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-dune-light.css000066400000000000000000000021071301406513700256450ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-estuary-dark.css000066400000000000000000000024361301406513700262250ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-estuary-light.css000066400000000000000000000024371301406513700264140ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-forest-dark.css000066400000000000000000000021261301406513700260270ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-forest-light.css000066400000000000000000000021271301406513700262160ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-heath-dark.css000066400000000000000000000021161301406513700256150ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-heath-light.css000066400000000000000000000021171301406513700260040ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-lakeside-dark.css000066400000000000000000000021461301406513700263100ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-lakeside-light.css000066400000000000000000000021471301406513700264770ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-plateau-dark.css000066400000000000000000000024361301406513700261640ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-plateau-light.css000066400000000000000000000024371301406513700263530ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-savanna-dark.css000066400000000000000000000024361301406513700261600ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-savanna-light.css000066400000000000000000000024371301406513700263470ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-seaside-dark.css000066400000000000000000000021361301406513700261430ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-seaside-light.css000066400000000000000000000021371301406513700263320ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-sulphurpool-dark.css000066400000000000000000000021761301406513700271260ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/atelier-sulphurpool-light.css000066400000000000000000000021771301406513700273150ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/brown-paper.css000066400000000000000000000015121301406513700244150ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/brown-papersq.png000066400000000000000000000434261301406513700247670ustar00rootroot00000000000000‰PNG  IHDRÛ# ÂŽbgAMA¯È7ŠétEXtSoftwareAdobe ImageReadyqÉe<F¨IDATxÚì½Ù’,I’fîfnn¾EDfÞ¼ÕÕÝà@!(ÂG¾@(†"=f!Ñ2ÃHËáòÂßàWðø9¤#g못dfDøfnn ϱ,ðî‹gWWåÍôp7S=ªr›êQõüïÿÛϾÿ~Ûì8ÞŠB´M-„ò{ {—RÄkÝ+­¼Onwó:=>>¦TxöàvïÚÖÄͼ¾ý]­“RåéôAÕÃëë‹ÝSmmBŒ»sª’¸ƒÂÓuýÛë5ßöøS;ãxŸÏçS‘„u{Ü}?4››œ³ßÿâw’¨¾¼¼JU¦Û®«ªjš&!ŠÆ4¸2ÄT–ÅjW%¥Öõî¢ >…P·F+_íÛ^ɺ¥Héñáüòò’b‰Xët;`Á¸x]&Ü|~ß}YxJÓ˜Ým>„’¡5-vCp~ÃSbºÂÿpD{±­v²mÛîöRÉóù²ã¾vÏŸO—gsú£,c±LoóøöøØî.ù½šçÛº¿>>\šú1É ~©”ôû¶º]•Ýœ”¢®•($|äwÌËøöö¦#e±, pWÊÚ~úòc¥»ç¿Ä2ö}Ç‚á8,Þ:ðàÿÀÿÿÿþüøÿ¶ø—ÿæOþE™L'I%§iÝ7W5 P+TÙ˜Ö;ßãkvïÛº¾-DšçYbǪt>j…ÒEΗsÝv²„½,œ×5º’¥µ â*¥°Ì£ÖHi¶‹³‹nº·rv¯´éM»®›ª5°^k-• " © ¥S*±;à6@¤¹Õâ™øåf7)ÊuZQðV[ÁF b·¸hB„ã·>"\Y–ÁGïcÓuó¼ˆRTº‡×m)j]™¦­àìy> bc^–¢(e)û®‡ùðÐ}3S–Ø»%P‹…úÙ®ó$’ÿŒã„ Fç`a,AT{—T)œi¼U€WY;ø1ùJ—¦Òv™ƒ›»ã£qßc!§y- U75ÒSD\…X”jZíéô`Ýv»ßN—‹I"#Ä„Ýé$ ½N°naD,2 ”µ‘Ì\bW*"ü’vߢðøfs»‘»Eª ðÒFÁŒºªVÄë|o»‘°ØXþðü}U×˶ú„Ï*8¨©‡¤µkmô¥3E Ø,â00JUGçeª+Ä1–áW·t]w¿…g&*ðÔmµç‡2ªàO6ëûR©”Ö1‰Ú K÷ÀÒ²Ž•Vp"ÒÊw¿ø%¬¿Ü§×ež/§A£‚F¿ÎSÙà÷ðb¬EÊHØšGÞqÈÊ•RXÍÿÿþüø?ðàÿÀÿ·Å¿üþû ¾ÖÄÃiÑãóe ÜuÄ"ж-núååŃϵ}E¯x»¬  à1BDÜσi@?JøìÒÚ ¼ª% ^ÎgìµiìDÁ$(Áuí ʥˢ\ ¬„{©ÓùŒß—¥1~}»­vûðá)E0pà›Ý‚‚oD0¼ªRpˆÒ’€¥ø±6°˜ ëŒ>F<ƒN5'ðIDÝ}\wÜSVÆ: Ê3ô-  / ]¤`Ù>D\‚ «*ë ¬OÁN×_1¸ï.2”Æî€Ò >ÄÏw¿"üST…Øo·¯¥Øa‡D0_Lš.)–ôØ‹ÝPš¦- M’í/—3R°Òµ —ü‚x€ · i+!iÀÜ Žp8îÉß,¾L"Uè®aRÀ7Ôó鄌4Í“bJR´—ˆ4ì ÏB ;¿ †¨nˆx?ØZ^`‡ÃpJXÇ­áø¯ok ê—2ÿ›§;þEy¿HX¥VëîD(p7xtžFÏ,pn°Õ"‰u“[7ìé=y8ì^j Yo¨†¡Ã¾æiÆbðèº6C‡D¹Oã®y¸\T±ïu]߯\¶ x¶°¤U²Z"Ëà‚RÂ’ †Gø?ðàÿÀÿÿÿþü[üË?ùýßÅì¶šº³ùùÏþøðôúz}½¾iYÁ÷@qÛ5«spâèÇþ– ïà6k“·ù·|Ðn&ÁEÎŽãëHe‰hS;\$Ô´½*õõ6‚ªª²„_¥BðU5"¤V°;¾ ýˆh|z|X碂 Eß;F…ï/° Zlv™ä"»,û¶añ`±ÓýŽåä3¨Ý˜PÆu]=>>"…!M¾Œvœæyô9ðà‘ÄÓ)R`d‹àT öᫀ þuݶ0 ƒÇ¿ÿùßÛ<²j…ú@Ÿç€¦nW¡fšÔ›[a¢Î´¸›åf`ü¼¯˜À •Ý,.œa¦qÆMxvï°Ûøòù˾¹¦i:Õ#7Ü—ÿ6m‹ ôz®ooˆßáÖ|ÀÜð¢TXüÿÿþüø?ðàÿÀÿ·Å¿üÍ¿ú=°ª®iaå~èÇi‚Æiêúá„Ë_¾|¶ë¤ )€aY îx”]_7x6ˆH; mÓIYÁ‡vÁMÀ±-pò ²ÜöÐnanüÃ:¤ZŸ.gØ®­µ©Œ†ï«†6øÕ<.Ûê@»®ÆÚà‘ê~¿cK 7àI¸¿P¬ƒÜpõ¶—`t<‰·ÆAœÝtˆÅ?~²«e<ƒ0ªTWëô{¢¬5 ×T¥À´àùÅ.ÀöéÄ /PØ(À­ë†¼Ù“äÔu}:àR˜”˜c’(—Åf>YŸ†3¨çývC@âqvs,ö’@-¶3 åmݹ`@v/lº LJäAð‘@ƒ-ýŒcpÍ<-!x0ÐçÀÄÆÛ+S`É’Ót¯bÕ(¸zØœµï»ûýŠÅk-‘µ°ÁD¸kï÷[Yâ¡ 7àºMƒ-x··Æ€ÅâÉ!ÀQZðøªz'vøEߦéñá£Öfš&ë6 4€^§´¬xhýá»x Sc'¸pÌœ˜Çj_°¶$ØFÆu»_YcdTæ•*¸ÄÛ¤}`*Ó8a'1ŽUJ4Çßü øa<‹HBtÜԺ)Êv·v-A㺎ôwµ¬`-Ãõä‘!ëëJÓˆ~üôÛÏŸþ–ŶqO\öãü6­£iwÕKQÖum¦ymXFKTÒ,³%)Ê`Œ.AØ©€e!@Xh†Ô¸S±ÒY-(YÏ¢RUc’´9b§Ä–p¼H,åÆ6l­ÄÚÛ¶za»mlÅ@LàjVÂ5p£TàZ}¥žþHÙ´wƒ…ߣ8ƒù}€D©$~‹ €N¦ãW Ø »FèÆt¿½{?>7»‹€šßkU‹·VÎ;¦"Qâ>Ìk5â©A&›¦y~~F”!¸°|d-l·ïMXJå¸l¹Ù ¤i«?_N— ¹ƒÞ3 >ùª–{ð–µwê4\vÛ6ƒôËŽ`N2dùïþ8…/'v ôô9d§ðxßõpz,ŠççBIØ^òmTÙÔ@y†sš§™4Z•nßx\ÓI8»‚ÃÃϦ“åî+”FÂÐÖ›—‰ñSÝÐ4m[·5¦äÉã>Ž3|:üø?ðàÿÀÿÿÿþ¿1þÿä~·m{‘Â8Þñ7z˜šF< DŽ£?<=€ òÀ PɪY¬²³ÉŒÀB°Ü®íaME¦$þ“òH÷%º[Y9%ëè½®”Ò±€ ì•g-p~]WË:ãu þgw·W¥*™.m>8Ðns°»s+>þøáœO2ʺmåjS‘PmO¥”* ÈñùÜKvŠT‚Ç!r\oˆaà «º¾ä©LT…X—áÝöMôXCa{|mxHÞ%ïü2¸ãˆ(/3¹}án8\»`!{I:aD‡·¡•"n»ƒ¡ªÛõuµ–§fÖEœ°ì7üQ°ñÄc»‰Ù§ˆë²€ž‡ß¼½^A… v«ññ™W`f‘íá•2€ÎöSiZq»½ÁbàÓ‘TŒÇU°’QÓöm×Ã/ˆƒ ñdWì(Ä5ˆKvŒ¬µ†g#û¹Û¹,ƒRˆÍÊŸ}÷ý0 Ÿ>}ÂbžÈ¹á³èpO%Ãv™Æ¯/ŸÛ¦}§­ˆ´ nVèExn< dË6H»(²ƒGÔ† ûF›T`ƒïMqÄC³ä5MKÊŠ¨À¥ùòC)Ø0âÙð°âPBt!ÍÁˆEuY²r éµªšºžÆtœ}åþüø?ðàÿÀÿÿÿßÿò_þ³ÿ@¥¨àÍvxÀròéé1ÄUïðP¥£@K…Ö(g²Ûúüñ[º^¯%å–…. v³I€¿øå/†áüõËWK¹"E­ï`xí4£1æt$™Ö¶òÎ%> &UT 6ª"I®•j6Ÿ(éSׄhm¨0cA"Ób!È’_È ]üÌtÏM¤œ)Ó n++M|…„ˆÁ}i;ð(\‚ó¼,Ÿ…±D­(ÉEÉeDr ØšÂÔºëûuÙpùó‡gÄöׯ/48‘ç^€ìûÄ.ð#·ß_ß¾ ÀÜód÷ð3K÷ûø¤•Ú6±'šÍÔm+$ʦÃÍ »¸EbëÉjs£øX¬òñ (/ëØàËä9H)äe™ dJó°‹nÎé‘ s7FÕ¦åé˜n¼‡ØbŽÄ4Nî ì¥2í»…%b‘›ÜÚùNÛæß^ßðmÛ6E¡tQÁÎm "£F¦`»5…_”©Ü· âÃÇglÍ€:¶-Bd”Í r™gpVà !#Syj«Ü‚\ ‘+Õ²4pK4ŒdF–ê¾®È+‡Aå žÐtãtƒ£OÙÉ7t³HÀPßëªðÂøÝ"ÔjivkEŒç¡C*¼ãÿÿþüø?ðàÿÀÿ·Å¿üͯ໾½Ü®oø[:\Õ Ý{Q¼15[ªÚÛXkCdz4^ìa§;8«'é_,ì<â,²RŠÇ ƒ€&k¬R‘Ä ‚ ³É6¹ýYJØŒKvRƒ-à‰à:5qaÓ Pm{˜øåë ìåöýt:ït -¾¬ *ø|¤µ¬×ë›÷®mšÅN Æºb³‡6ìc½ƒ¬¼¾’ bm±ÀGê@¨µnVÓ´OI"ˆNʾ‘̪n ]êNg¸ÇZw¿ß/—Kß÷/¯/ï  M8`‰`8ŸÐ-Ïô®;ÀT²1—à´æ}ç7ÄC? Q\€%Uù”M’ÞR»®‚ÛÔy] B.$„D> ‰MÛå¢1 ®ãyÊÆú$ÄØÝÔÛÃo°ëóùʪ&ÄU¬*øÝÓ¤xATˆi ;-’.¤È]Ð]?ˆTF¿! Œ·éåë ýìûïdÎŽq+v ôó|›gÐeçÛuëLs9pÛÎʹ‚Çv6w:ãcð V €viø”{1j–ˆ)¾ )ØjœÿX•›Éù‚D‰K0*¬Ã4@(ØÒT™¦gD¯dÍÛ[6ÊIJÞ³E‘ÀÁ—"Âtup;ß&ìžïþüø?ðàÿÀÿÿÿßÿòÏÿø÷ÜjÙÍ:¯ >é+„×/¯¯¯/1mM­@ܰÏ×ûX5 ^dipªß“*ôãÃó>š7¸R7ºíNu{ªÍyžW*.öþb‰À¤nº +e£Y9”åDYU¸†…?€›}þòyà(ãÒçwìNóÄ’(AáK°Ÿ²¨b>)3,úoB@ª˜ÇñªtÕw-~CÆV–5§6ûÆJ²àØ2Áí ìs- d%¹o+¥Meê&¾ûð¹ r¢Œ<0ñxJ—þÈc3„n#K}»Mv^‡¦šï_×ÙÂ-Ûêï׫µS•2°Â¦åën¹Ô˺Ó!}Üï¯øVhWàûôøô ŠýõíÕ;ÐläMä&ÁÄŒ p ì¯`öX ñ³#_]•òº|TÂ3v”ö&J9¤TÁì@ƒ¬Föȳ7eË@H¯ˆ½‚5v{)TòÈ$µÈHëæXiç]ß´Ûº1€›:D7Mã|7 ¦"Ãñ~»$fQpd@U+fcwÖ{•@Íÿÿþüø?ðàÿÀÿ·Å¿ü·úpVVD½÷®Q²îšþÇdTAˆ¤Úvh½Î‹iÚS–Æ&ç¢:·eYAÁõˆ{j‘" ä¬M´#SÔX“Û6¯äå¸Ïp>ëZ‰BÜÞÆ¯/_ó¹g8ðàÿÀÿÿÿþüøÿ¶ø—ÿËŸÿúéÃØËz‚»Wà•ÍÅF÷}k·õíí ÿøá;0ƒÝ­5u'ñÜuM]I‚`’ª¬¨Ýù‚c5ÞyËh G­ :XUÍP©@yÁR´6ïÐ\—²iOºnú®Ï``Kˆ,Éh£3›”°àý>–⺽]oIć‡Çªª)Á˜7‘å{Ø 6·ÂJ"Õq/Cpãü ØÂ׬ö2a·ežK¥‹T‚”³øJU—¦é+Þª=„ñ>.ó”gÀAíýÎÞ¬Î*så@í90lÀöôrwÓFÙ$»äNvŽãœC›å¯ütÕl®x-Co–u €cšCs×EÑa=À^þãßùϱG˜”ú Ô;˜.O Åj; S–úzŸxîUŠÐ¢íZ‚•ev`̵H8<ðòì /€^ âáò.à\/¥™VǃáV`ù`çnK6€õ}ž±ö•åLBû¡_ÇÙèê~½"àDúÓÓÃÃÓÃîÝËë+L<Ì#>X=<\üø?ðàÿÀÿÿÿþ¿-þå¿ýÓ?Ä6¦ñöÿÍGQ±ÓYbK÷ñ œÕZ?=>+²4gLå£#)’Ö¦¨;À«© 9N¯E†a0FÅè@’8h”ݸe…§jvIÃa^ð@„Ÿ?ð,É}ß³ex]cVÔS¬2®E–!ï÷”ÜÏ~þý´¬"@³ € ˜º¸OÉYª—j§qrÛyo5µ3«uæªXØûrr†Ó®Ë! Ó¦ä1T ëÀd¸žUM¸m³œ¿15–Óô-€œØZKJ× `ÝÃåCßÖR ´csÏ% -{#"#bQ(ðÜjYF 7bAOÿJá!ïJîà]_,Xå#;ŽÊµ1¤§Á.ì‡ÝmÃ2,8ã6ÞÁÙ°<«…×ñ|În¶Èó°qÿ®€ŸUy†~YmÊ“`J—¶­ßÃ<ÏÀS7PSUüªsùî;R]ˆå\Õ‡§'p5ý*“À!í‚®òPÖÈ^ÝÁ°YÿÛ>µCtÛØãîú¡i<{Ø«ïù÷Χ˿ÿË¿¤t§¿Ž½áaÐÛË•mÍJ½]ßp1Í8®»[ÙÖRð ¤ðÆ~Üæ¤*ØšÂùt†óÀ#/—ó<]7¿§ÂY`5ìßa;0;8•J ¢§¶–ðÁìF Wö.óp p„ѬۣpM[•J¬ÖR¯^W)SÎBБMëòv}ja-ÜXVÝ9Óa‡Ȭ~Ïâ³HÙÀZ5:ÔP©È”è‡ùCÉIEÊM (F;ò•T‡„íÜ;û—câè.ïúSÇ‘¿¬ Su f™‡pܰ¯+­~šÀþÍö|ä)ÂAIÎéE„7KYŸº ëR. ?Às±ž?ðàÿÀÿÿÿþüøÿ¶ø—þëÿÈXnwYŠ~økUÕó²+ÙðʩϷ%ú3áU74*K»/ ¨Ô›,©è.bp+%Ó›FÃ…àaUZV:»ƒ¤QŸ²ª(ßÙ-ÏXXeÅÉUÎn•®Áئ}/ ÚÝ0ÕuƒÝ}pê²¼7p䳪¯oŽ¥T`– ²8– +iAÇÚ;\fVÂO²hAåNÓª<‹‰†¯”Ï’;€bìÛh½­è)~†è,òx-pQ­ŒØüÞS*ù>éóŸ2«šä‚p\W–m«“¯‚øÔ.² @£¯÷ë?øèzXƒƒy.SýuM•ö&W’s<ç–‘S‰Ã”Àgèã|[Àžê=nº¦”'"dÚ=¬;KÁ¶óC¦µ# ˜ûÕ%òQ©R[qÈ0"w‘Z!´¶}kš:ÙU-gÒö#ÖäÛe£0ÝF¸¦¥5Œ–’U\5{± 9R<ö©~Û@ ‘"úahM“[ÙCÉ @‚ÍæÑhø,}É8Ž„‘ýœK‰~JèG¢%w%“Är €Ü¶eš¨¬Ôt¸7Û2oGöVœß†Ût-ßpx!†Ó™ï¸UâÈ7σKǪÄP ýÅÑë+‹üø?ðàÿÀÿÿÿþ¿)þå¿ù“º M¿×ÿÍßþÍÛõë?úGÿ釧çuµmgp‰®ÁÛ´sàMU™|Êàçî,›¢c¤&»ƒ9J‚ °NÐOê² ¾@EDÖBg±>u½l+šDRºb=Võ®¼ÃºyPÛè9µ[…›ùô¦ÃÅX«mðœªæ™KÀ5 6§nkHACvU÷ûõó?™OmNÁ&Yì´Î#°ªH­QàãzÖãÉåÞ‹&«ôŸN,äIp±‚Âëu*â–›°§e¼â‰À7¼‹mÍnÁeUm*S?>?ŸÎ[ðm?ÀÊóãß ±?]NÞ­ºšªé~å=ìüáé+v7;7¢ë‘eÊ|üg)ÁE ±—óIpÕDÛn+ ÃÞVƒ–u‹ª¬ÛzX¦ФŠÐöNúKÊ× B™Ê÷œ¶ãñ Î ‡Øö†D:ä ˜iGã°ÿ0œñµØšIøÂk]ÂëºõÃùãw?$¼€B±üSWUžÆyaGKE1×)»_°·eÌ3º f&v´Þ ‘*¿¬{5ÛcŠl{ÙÖÜ…ÍבMÖ†Íõøât‡5Qo*rØøºiy#ë× `,y¤vaxïÀ–‘¶ƒ…oNXœÆw’CÒr zàÿÀÿÿÿþüø?ðÿmñ/ÿì~wž@<§;©Ußÿüû¿*“ï΂jHŒ#\µ×¦VŒ®Ó]_Þ^¾|]++JYÐEΣ²€ M€?Ù¶M‘K‚Üî ÁÁHÔå¯L™ûL‹ÐãÛ{ÜØšTg:lÔűª3V%ŒFÔ¶-€²®K>¶PÂ=1Ï•=ÁÚ«µØåj½®“]gDg 29+Ø&ÖˆÁbá|pÓ¡ïBÚOyŽk¥XnÊøøx6mS›Ðÿÿê߃À=ø¸±Æ?zøI—áüx®9‚J™ˆÀóã£`§oÊí&ì_†õ°0€öýßÿ'hÑòÿáíóø©úÏŸ?‡ÍOãÊ®•èaögbùÝ–2½O:ÈsV©oÏeÜ=à‹-nøQUZ‹0 bDüúòõ~»œd%µ)³cê>fáV!sd±O~aÝyòpÂoA7Á1Yý4Õº®xº§dÔwà)ë}ÆNÁYUKïóJÙ{-"öÿ¯âB$P™èö†òÈ æe—ÅN=+ñ!äd`ét¾`]ð·Ç_ÐoªÁ’(@ëÇS<Ó”F)Ué™o@µÙI£ØUÍ*,O–…%kXžÅ±`T;²+ÃÒsno ÒŒ‹ ’º¡Õ<÷ëëåáœÞ[üø?ðàÿÀÿÿÿþ¿)þå_üéŒ …îaYYUçŸ?½þÕ_ý5V¼nSÈ­¿¦YŒã8ó „ÇIŽÈG%É—Ý8ý°›Æ™Ã`92Šº¢×Û5Rƒ“TǺmœ±æ¥–†\5¤Î4 ¼œV5Þ)TðPÌ̘’›17e‰G9‚Jû…Z ˆÃ=€ÔÂsCŃÍS­Ä)J}?”œŽ[ƒZœÖ!TL=‚k…iØXQUdi‹mLMÎJ º˜»%èö—·û¼¬ìà¡—„/Gsi„Ü}œJ6.4•6Žûþñr‚Ý×u~~þˆ¥ß¯×e¿|úqÚM}îOÁz­jeXdõüød-â³yyù‚dA‰Å2,ÝåÝ¢äõ|FžÐmYΟÕ`ØFc(à~ß6 ìœÎmÛ­vAʯ \†ý•9ôy8V¼³Mxj£“œì;©óÀ\šÔ#àW„(#|½w°R'…·Aå8’ª¸<<4ÁöϧÓt Nç3¹þ‡*.Ä"’jÃó% é³ÅXéú|>ÇôÞW^è¬þ“8QV𘠻ÃÇ&ö­’œ0Í3ÛØ£/xŠW‚Ú"·<‰ÃÏ…Ò@HÉ^uäÁ*ŸrÊ\ ×4óf©ž•žaÂãÙ`Ǻ10cÇÃ)¤(j Ö5n‚À8ðàÿÀÿÿÿþüøÿ¶ø—¿ùï~ÅÂÿŠÝ»mw:Ÿ¾SU“‡£N]Wk­ú¾å u!´©.—óh—Ù.ݹzz2]ø·~ïý!ô.˜[Ë˲ÂvN— òö÷³*k`C »A$Ødm²ðQ®Xª´d‘ØnÜÀnžËå4Èr!{ìA²R®[ö^íúùb³k7tìM–¥ –óh³1Ç lÀwú‰ííÀ=éäÎA]×ÙÍ+É),]וËÇ9ˆÆiYÓMë,JÐ\‚»S|õ òÈá’Z¡%¥ôO0SêKv²°®f{;çH0å=Áh•ì;ä Â"Ç 8‡~ >M}}{ƒÑq!{±ó[’ÿþüø?ðàÿÀÿÿoˆù¯ý+ö Ž8ªt³Ì´•V2©ªÀâvÇ3S‚¢9pIUu§!KA²W”#‹$çÓjY™üî½i4B¨n‡ËÃcJ–Z€'Ô¦†ómº,IM«ó §H`KZkܺiZA9w­X)/<ÐPFÓêy„øx+rKO: PíìáàÜ&P;Ö"9¿§¼UªE¦©‚^*öœÖ0í E›º±óÂ7õt\nŽ­d]„)Rº²úøñgX.õ5£Ÿç»1 s ó ºÆ’ ¸Ã=U­²Ú=$Á[ÈŸ$ÇieJÚ€ârôižµîE­Å1JáYžOO"$€ÃR€\jó”¿ñã}ô`ŒIÆ´#ðæeª}>Ÿ`6Œ˜õXê¤KAN‰ šÖô=Àælky$$~*C*©¯o|XNd vãQŽ©[]³#ØRäÈz# ÈÀŠô>ž~¸\À"?}ú Ggr‡µÛºVpØõzÏó³’svC–á¨[Á¹EdyYâ1 ‹É]Ó°ã[UYõ©HËjˬrI%¥“ä°+2ž×³x wf}U¯ÄyÊúÍ%M]3¡P'Uáçp=–Ô™{·Á’yZ³¤YiN@žxÜ£Jö2ïNIeS»‘»–ußö°ï²Ì`I¥,L§jNh­Aîã ÈGEì8æBvÝ €‡ÃXø$EÈêB¸aÉãªS:d(—êãÎË<›ÌÛàÔmeQ¸Bã€ÚŠ ¨ÌÂ>Ý Ö,ŒÖØëíí†ÍºÌ]6·¼|ùwÎ7ÏTäòr~`(J™!tŠÃ«üÎî–:aó;§Ñ²e¤êºî'ÕÝl+Û&ZŠ±ÂŒ­†Lº•EÅN^½8¤š¦m—Ù‚[m¹ZnN1wM_.=ŒòèZUä tjà#7aTY™¨¤´ª`ôΦö”œÎ…ä\YðØ\FÐó%GQ!š€u•–çsØ/boÙì^tm“Ó/«¸ì²8ï {otV”Rlõ($ëêæÙ @n‹À3ÏëÛW›ikÛ6È’ÎÚuæ 2ØfÇy¼§þtê8.z¶ íÏbš§ÅN ôþüø?ðàÿÀÿÿÿßÿòÿàŸãïö}ßÊv²íX"u OÉðXí©?·§öjð±’а sD(–\P:‡š‹¬Ó¢!ö–…8%@&Ëâíõu§<Ü$@,Èf|M±{ƒm©ØdŠÂSit"ðœŠ%ñ¢U²$jm©JY`Ô®‰åGªúîg¿¨Rùöòu8µª*²ÅHðMß²¿ØeO#c~çïÿGKn1†iªÊ\ÎO·ñE‚øàvÝ’ £€žjÙ®ËÊ^Ø’­à¦¶Ã Á¾ðó¯_?ŸN'Ó€Cwà=÷é†tá¼Åú›ÄYaÖ÷-kÔ8›‰H˜ç9ìáüpþixkŠ0} ´éúÓП.—·ëužæM¹[Þî7Ÿ«š€áóãp‚š›Ž½ × œ„’ÊP3vŒ`F6Ø=’Û–aÀ‘¶€Ô8Ͷü€¬”ÍËÈÝ"7]oWìk]f<»Íy„UQdýÊW°aQP´, Ôö§'%ýÇq´|;"º®w`á"¶-h·æ(\ñHHuA‚øÏѨx–d¥Ê*ëü;»pë~Çba<‘¥b©°ÎOã8ÝfŠðS§©ÐÆpò-GÙŠÿþüø?ðàÿÀÿÿo‹ù?ÿæ±ýiœ@Zpð·íÝp‚Sp#â@jç¹(§Ik]î©(€¼’•1U£ÙÃé„us¸mØW»”%džR®\'8Oš¶¸< …òH#E8 ¦ÀvbX‹C›˜®\|WÆ!}"O¢û©ÝSkØ èl; ׿½¾dU08‹Nj ¨×Ð÷q;½›µ'ÛÆ\¯·Zë¶;±Ü>J矃M+G@uuÓÖætzä [¸q]MÓ ]·dÊšÝÇî~¿ÃÔu£ó쥸LkÅeš7ÀÓ;‚ñ¶mû8¾Æ,ÞTP²S°·7yNjÝ6ž®šÜWÎQÀp 6SK~y¼\|äÙJÈr9& fðEvu‡@a'Q¼ƒ²È¾°{àcYgv‘krn0¹ÓåŒäõòòÈÈó†Ùv,Œ»Þï¦fy×w`™H<À VΓòòI ÛgqdOt ¯£&+%rvŠ…RÖôtB$cŒôu6Y˜S0â(ÿÇÁ8„H-ßOp’1KÉ&q™çùœâÐ+Ÿ'å†~_¥\>xG@±Ý6µ ÚgL£˜,¶,JöPƒÁã iWDVd±U_’sÃùt¾ ÙáÁ S«u3yÕ‚óàTß þüø?ðàÿÀÿÿÿßÿòOþàŸ ì›¥jºÈjå$"Š;, ¶‹VÊtõ<Ûûx‡K(­ÏJ,ΈÚCdíW¿”ž1Àôήy€“¢f{–ÝYØD OS™y¾ +˜´vD,Á P7 äŒ'Np@*@Ý ’­a_lYÓ°Ü6ŽwêºËj]l^ª l>[’‹ÞûŒY:r~xÒäIj™æÛõ–µ’*AÕÏô·T¥t¬5mÏa^À‡Hv¼ßב¿*Ùt;MRšçµÌ²7 È-ÇpM¸ 0ñ½\.1Ÿž`@[Á 9¯,Þw}UW]BÙ€lÕMM£Rá'1Ià mZXö}{C”>?D° £L#5‰*Y"`XžuÕuô$¬-›‚ñ0iÚfäI ÛjÈ2œ J.8=Û-²ÑàJà[~ùüyYlÛhc[â4Þ¾¾|†ÇAì´é[ª´ ç×,×*sÏ aRó¼A$)¤’eÛ®ÇÝ@+ë¦a/¶²(;¦Ö$k«$Ã4FðH Áñ@’s·8V ô<…ÿå±[éçûœ0ö¹(¥Û¶’‡S¬ŸÉ«¨$Œ¼ÌHG+Rƒ¬8ýó"+óø3ê°À!–ÔT XÇ„|jÖ4†=à:Ï.æû æÿþüø?ðàÿÀÿÿoŠù«úŸó@ͺôïj1‚‰,¢ÒP‰‡Ç=¶]ÿðpïóý~æA/)ö"$Á o·[®g¯±ˆmßn°VО෾£º;«…¤h \RRZ“Ý’Ï¥\›m þPX PV ô”òˆwy¸ä#¤:NPÒ”ÝaD½ÏLhªZ·l©Í3¥BŠÓœXåîbTKßÏó’‰NÉ# kqlÄùÝ®óõë§ÝαJeÁß§§:àQ ?ìœõ€ŒAäÀ؉­k“ÅtÒ´L²¬Sk`¤ÁÚmA¨Ùàf·Ý9Œ|6"ÀÔêI`ÿ?ÿå/àýiž±NϪê zâ827Øèëº)88q6lÉ™½ØmÓ´ŠH ˆRô<èѦE®íæén—iYî vìLç̳Ö97Žã<-lFÑ&EàþlÚ–ÝÛž²k€)·9ø?ðàÿÀÿÿÿþü[üË?ýoÿKI±O¶ “i¾lF%»mSU±‰"p‘ÀffP¼ëµz,l±+ÁË WdvXKìÚÎsJÄj¡|: @¥ØP±ïmÛç)©ÙÌM%ÖÄP(d%RøèTïɵasßµA°ZˆÔ“TXhSGqÃw–)9(«Á¾q* ÿ‰ÊH¥Êhwø¡]k5"<Ÿ¿c9£±“‡AR—ßs¦V´—ïÕ:”ß_öÓé Üyð°Íõ}÷Û~ÜCq>Ÿ¶}ËuùLmß‘RÎÔí¾í’M)ÕívãÑ ÷º†´Ñ:x¿®J‹e±X×÷Hð(4ÞGDPßv%üM^E2Š] žÉûj#ç&DœùŠ °ÊM pùLS¸ßÙyuÝÀ­ì W KêÚá|ú U_ˆƒs+¬§+¤ñ»HÙ”ó4²›‡e‘%à‡rDY¥‡çë¶ŽëÍcƒœoÀé»n¨* H ûÆ“9À±à¡ üYÓ8ïÎw((ñ÷°—%Å;9ñ«ëۇ˃ÅÅþ.,ŠØùàgÝ6 Ó²“]‚³{†ç;BQCt¹MK3Þ_aö®¯ÁnSÚqæ9£D>[×…S´˜Í öü,kÓ¶ö¼NÎY¥‹ÿþüø?ðàÿÀÿÿo‹ù?ýÙžOµiYì/)¨HÀXžÇ:;åZH2uô>µý)W@…ä|éKë7׺u§’eòeòû–o‹r‰¸ [KYq –ØSAù Ð)vKH‰_YV…x«|®$òq3†öÞì}·Ž[2À·ZæEäS'04¸¾ÄFaMøÍÛõ†]3HHFKú±Ô’`Ž]×'áqÛ¢`¥R×éÛýMH äí1<}x|¼\ÆëXIjè(Y”³a;îÜä㢢lö%L=°#º j›< }º<Ó(ÊúµmÓpùNvõ"z¥ÊóÐ;GÉzV5°HJÁP‰ÑÚéúúzN§‡³*àïë˧=lb°Œ{™à›þô< ðöLý9V—¥]È\ód—‹¤¦YædltØwÜ`O@UHo/oÈvå|``=g†s™Ë§‚¶ 1W ˆ0Nž ¸X–]—ëõ…óÔXÉWñ½f? |ÇéÂMª, ³Ã2Z¾cÈljˆÉ¤ß«|óiÀ®mMS[çY†e:v‡ëг |(²Jg$€R¦¿ ö  äúœš+|­ä ò*EÛ5ˆÍ•Ã~E7 ©1_  &pD’B>Fª¥Â¨]‘£Û¦?ðàÿÀÿÿÿþüøÿ¶ø—ÿãŸýá¼®SF*P‹¿³7MsÝïc.Êas(žêàR¶ Óô>WV8» 5‚O¼Ï½Í²•v^gìÖpT•À'ϧ Øçýv+XSårKòO]RfáQÊ¿­”„l ;šCžo 2Úèñ3Û•T©”hÞõnʰD(°·m”pÇyO6©9s•¤|:Š|d"%y6¨ªÛyÔ˜É[·©Ê4ý2]Å—OŸçuypÓÐ?,ë_ÂuX2\‚[ÔÚ ðú¡É½ÀY\,E|š¦sH Í ,ÈÎ3§¶§àÇïã¿ëûS‡]ñ¸âöî}4ë{Kè1bg¾ß‹’í]ß±ÏC·å:Ãz)ìôÊé\©ÀNð),Ïp&X£^owIU%=//Y^Gä3—,xß—ÕÝ8l¬dºƒïVkùÎA€.#³øÆ˜á2v»/ ±úvÀƒ®×ÛÛÛT+ƒHÒt4±©%…°¹}BZŠŠ§4|Ù°m[¤âRƒõÏó,5…a_^>;·=<<"ÙÕ¸½ÁÚÆyj[¤cs»ß€#4Çò ¢¬¨¢OÂ]æÑÉJñ ´*ÀrÝí@ÐÛ¾`F lòæ°ˆ‹ˆ¬˜SJp]€všîˆ4I=Z…!›¶¯TuàÿÀÿÿÿþüø?ðÿmñ/ÿÕïÿWl蟜ú î¥uMašŠ®Å_ñíNʊǦU­ö}µ›Õìì¦i4^ðp@ò‡n/ç‘ÖzYìêlS7੉‘à`b\0­3>΀QòÔ÷Ã0,ìæµŠÊøœ/Kþ®WRåFãÝ;¬œQÙ¥››aAÓ:Ód„ÄñZfž&êºwMØÓ¶íìg­P͎ÓXµªgp˜íÛwfÁ<ãn¢¨­u)7\“Qƈﱰîaž—ZWy*%‡ê2p$,œ.pƒ~‘\7¹Í± ·ißì4MYI”tª`v1ôgP&üì«k{I6†ÄÁU?~<ŸNˆÿ××—:€ºÀ²Ÿ(ªš x .GÆ–r,ržVÃ~”\òì7lµdÑ•ÝàÏÃÇÆŽRU@aÍy²ÎH /¯¯L…ˆ×Ö’ÍÝ›Vc%Þ§,cäK²éĺ®Ç©¬éDÓœvðtDÂý:}Cw9?~Àš±r¤6,po7I™¡z³ÆÞÙHÌÖoT)­¤aÅ=±AÇ€ -¨ÞóócC²›‰+[mŠ—×/·û’âùü ßîש¥?±ƒ ïãLY¢HWÆq–/âYåVhX™ÜWp¤ð 7Ô#Kæ¡Ê‰uct%S+°Lw>]*N)[yècdLV⥡EÒËDf³j0Ùæv™á|$›’C¹Àø“'Á•þüø?ðàÿÀÿÿÿßÿÿŸ*égu¢«¨IEND®B`‚cbmc-cbmc-5.6/doc/html-manual/highlight/styles/codepen-embed.css000066400000000000000000000015121301406513700246500ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/color-brewer.css000066400000000000000000000015641301406513700245720ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/dark.css000066400000000000000000000014321301406513700231030ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/darkula.css000066400000000000000000000015721301406513700236120ustar00rootroot00000000000000/* Darkula color scheme from the JetBrains family of IDEs */ .hljs { display: block; overflow-x: auto; padding: 0.5em; background: #2b2b2b; } .hljs { color: #bababa; } .hljs-strong, .hljs-emphasis { color: #a8a8a2; } .hljs-bullet, .hljs-quote, .hljs-link, .hljs-number, .hljs-regexp, .hljs-literal { color: #6896ba; } .hljs-code, .hljs-selector-class { color: #a6e22e; } .hljs-emphasis { font-style: italic; } .hljs-keyword, .hljs-selector-tag, .hljs-section, .hljs-attribute, .hljs-name, .hljs-variable { color: #cb7832; } .hljs-params { color: #b9b9b9; } .hljs-string, .hljs-subst, .hljs-type, .hljs-built_in, .hljs-builtin-name, .hljs-symbol, .hljs-selector-id, .hljs-selector-attr, .hljs-selector-pseudo, .hljs-template-tag, .hljs-template-variable, .hljs-addition { color: #e0c46c; } .hljs-comment, .hljs-deletion, .hljs-meta { color: #7f7f7f; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/default.css000066400000000000000000000022071301406513700236070ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/docco.css000066400000000000000000000021651301406513700232550ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/dracula.css000066400000000000000000000017701301406513700236020ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/far.css000066400000000000000000000015211301406513700227310ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/foundation.css000066400000000000000000000020761301406513700243350ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/github-gist.css000066400000000000000000000016271301406513700244160ustar00rootroot00000000000000/** * 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/github.css000066400000000000000000000021741301406513700234500ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/googlecode.css000066400000000000000000000020351301406513700242710ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/grayscale.css000066400000000000000000000036561301406513700241460ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/gruvbox-dark.css000066400000000000000000000026411301406513700246000ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/gruvbox-light.css000066400000000000000000000026421301406513700247670ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/hopscotch.css000066400000000000000000000020431301406513700241530ustar00rootroot00000000000000/* * 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/hybrid.css000066400000000000000000000024761301406513700234540ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/idea.css000066400000000000000000000022251301406513700230650ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/ir-black.css000066400000000000000000000015471301406513700236550ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/kimbie.dark.css000066400000000000000000000020531301406513700243420ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/kimbie.light.css000066400000000000000000000020541301406513700245310ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/magula.css000066400000000000000000000015731301406513700234360ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/mono-blue.css000066400000000000000000000013551301406513700240630ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/monokai-sublime.css000066400000000000000000000020021301406513700252470ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/monokai.css000066400000000000000000000016521301406513700236230ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/obsidian.css000066400000000000000000000020671301406513700237570ustar00rootroot00000000000000/** * 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/paraiso-dark.css000066400000000000000000000017661301406513700245510ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/paraiso-light.css000066400000000000000000000017671301406513700247400ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/pojoaque.css000066400000000000000000000021441301406513700240060ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/pojoaque.jpg000066400000000000000000000022421301406513700237750ustar00rootroot00000000000000ÿØÿàJFIFddÿìDucky0ÿîAdobedÀÿÛ„       &&&&&++++++++++    $$#$$++++++++++ÿÀŒŒ"ÿÄ^ð!a¡1‘AQq±ÁÑáñÿÚ ?ÈaDŒvKgÃͳ’¦©-o¹&ùœ0 uϵf 3¶>€\\QK޹üço¹ {îÀ(ª"Ø QKlîko‘Ž”|€§æ¸aÙðÁj"Øw¹… \À¥²TÀ§^î* o€ü°ÎN8o3…¤d­û;Œcȧ<»€ZÀªp´ HÐE°5¶pPÂo´úZßNÞÅo³0§,dÎùýß×w Aß?inÐ&ù<}*à‰á‰×…-ÞE:v7mÜ*H›ä-g!DåÅy¾ìŸڅ£7?"ÏÀZ¸7Ë ~o»\\EŸf QNM³¸_À¸‰¿¡7ÈY| ݶ`— ›è uÈ‹>ÁUý0¥²TÀ¢yP;¶ò­öaUñ‰ Ë)¦ «úaÄùŽXnïà ß$Z•rò* !ù>Ì[rÉÜco–Q[á„Z{H‹côŠ2 ¯Á)ßà -³ù ¡½¸ªv´‘[àQH‹bRÙ On%H×û :a½¸ï˜ð5¾î4¶Ì§£¶wp¸€¶GQ7È ­ðÁsÉœU°¥²ãKw7ÈèUCiô·ÝËTÌINÿÛ8 Ráqö°&ù/wTð"ØŽ[0~yLØa¥°5¾îïäJ‘¥¶b®BÕA[%OÀ¸…Á„ß iìµçቜ–¼°¶ÖìÒþ‰¾~k{Ð’¤BˆË‰¾@U7²Ö8à¢F;@ [#¦ìÞÜJ˜¤ODßwø)×>BÕ˜ ¨ßIÛqqE.RÙo A[á…D[:øø)mÂÖß “üüòÌ)ù®v|0Åü–·Ùˆ¹…  [>vmœJ˜ëÝÀµ¾ä›æp–ÃéÇ àLÂ-¢a@ÖýÀuÏà§<…¬ §¹ {îà‹`ÔRÛ;Ѝa7È t ›ävö+}™€-D[âùýß×w¸7KdinÐ&ùU|ûwÔ´Qè2g HÈ\}ZÈ cȧ<»Ž‘ß\†ž3Û@ @´€ñÂ=€klãÎ0]òZ}-o‚%!£ù)Ë3†Zú¦@-|üo1ØWù:xúUÀ”‹Ü›ÿÙcbmc-cbmc-5.6/doc/html-manual/highlight/styles/purebasic.css000066400000000000000000000044421301406513700241430ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/qtcreator_dark.css000066400000000000000000000017211301406513700251700ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/qtcreator_light.css000066400000000000000000000017221301406513700253570ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/railscasts.css000066400000000000000000000022731301406513700243360ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/rainbow.css000066400000000000000000000017271301406513700236320ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/school-book.css000066400000000000000000000017471301406513700244120ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/school-book.png000066400000000000000000000007461301406513700244040ustar00rootroot00000000000000‰PNG  IHDRÛNl6gAMA¯È7ŠétEXtSoftwareAdobe ImageReadyqÉe<xIDATxÚìÝ»NÃ0`»EŒ ôAØyh^‚‡@êÊÂH%$È¡¥j“ØqÚ¨ú¾%êÅ—G•ÿ¥Î›ÍS—æˆØ_sno³N9Ým¯«} ®ØÍ.6Ïj‘ó¹cfeàš-”„m¶@Ø„m¶@Ø>“¿¶/,a¶@Øaûdߊ €°-lÀ òËûgãÿ„ïÎîŠßküãƒÏŽßßöðöœ>nWéõþ±¡ÝáaÑ¿&*߈^¥qçMcû{÷PªAmž-ý×îeXÛ]“s®É¼µœ~6J}Öj=Uçã¶9u)çί úö™ÉŽ\°Ö拵Q‹ëºçˆÝ¾1’ úû°ÔÛKMí«£5Zú-µK3ƯÍ!Æ(í'Saü±¼‘fŒŸFöªÃï-óW5]BË5û/ÏxË\N]—ºG‰jdøÕ‹bIEND®B`‚cbmc-cbmc-5.6/doc/html-manual/highlight/styles/solarized-dark.css000066400000000000000000000021711301406513700250760ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/solarized-light.css000066400000000000000000000021711301406513700252640ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/sunburst.css000066400000000000000000000022371301406513700240530ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/tomorrow-night-blue.css000066400000000000000000000022001301406513700261000ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/tomorrow-night-bright.css000066400000000000000000000020721301406513700264370ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/tomorrow-night-eighties.css000066400000000000000000000020761301406513700267650ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/tomorrow-night.css000066400000000000000000000021751301406513700251660ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/tomorrow.css000066400000000000000000000017221301406513700240540ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/vs.css000066400000000000000000000015051301406513700226130ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/xcode.css000066400000000000000000000020571301406513700232700ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/xt256.css000066400000000000000000000020261301406513700230520ustar00rootroot00000000000000 /* 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; } cbmc-cbmc-5.6/doc/html-manual/highlight/styles/zenburn.css000066400000000000000000000016631301406513700236530ustar00rootroot00000000000000/* 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; } cbmc-cbmc-5.6/doc/html-manual/hwsw-inputs.shtml000066400000000000000000000053561301406513700215500ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/hwsw-mapping.shtml000066400000000000000000000067331301406513700216610ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/hwsw-tutorial.shtml000066400000000000000000000142301301406513700220600ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/hwsw.shtml000066400000000000000000000117711301406513700202260ustar00rootroot00000000000000

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

cbmc-cbmc-5.6/doc/html-manual/index.shtml000066400000000000000000000033221301406513700203360ustar00rootroot00000000000000

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

cbmc-cbmc-5.6/doc/html-manual/installation-cbmc.shtml000066400000000000000000000047421301406513700226410ustar00rootroot00000000000000

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. 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. MacOS: Install the XCode Command Line Utilities 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 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 use CBMC!

Building CBMC from Source

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

cbmc-cbmc-5.6/doc/html-manual/installation-plugin.shtml000066400000000000000000000031111301406513700232200ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/installation-satabs.shtml000066400000000000000000000112021301406513700231770ustar00rootroot00000000000000

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. Windows: The Windows version of SATABS requires the preprocessor cl.exe, which is part of Visual Studio (including the free Visual Studio Express).
  3. MacOS: Install XCode 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 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. 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 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.

cbmc-cbmc-5.6/doc/html-manual/introduction.shtml000066400000000000000000000150601301406513700217520ustar00rootroot00000000000000

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. 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 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.

cbmc-cbmc-5.6/doc/html-manual/ireptree.svg000066400000000000000000000244051301406513700205230ustar00rootroot00000000000000 + operands symbol typecast identifier type type type operands symbol width signedbv 32 signedbv 8 width b type #location identifier a 0 1 0 #location cbmc-cbmc-5.6/doc/html-manual/libraries.shtml000066400000000000000000000035601301406513700212070ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/lock-example-fixed.c000066400000000000000000000006271301406513700220050ustar00rootroot00000000000000_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--; } } cbmc-cbmc-5.6/doc/html-manual/lock-example.c000066400000000000000000000006151301406513700207050ustar00rootroot00000000000000_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--; } } cbmc-cbmc-5.6/doc/html-manual/modeling-assertions.shtml000066400000000000000000000112011301406513700232100ustar00rootroot00000000000000

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).

cbmc-cbmc-5.6/doc/html-manual/modeling-floating-point.shtml000066400000000000000000000145601301406513700237630ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/modeling-nondet.shtml000066400000000000000000000054611301406513700223200ustar00rootroot00000000000000

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.

cbmc-cbmc-5.6/doc/html-manual/modeling-pointers.shtml000066400000000000000000000077611301406513700227010ustar00rootroot00000000000000

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. 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. 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.

cbmc-cbmc-5.6/doc/html-manual/pid.c000066400000000000000000000037361301406513700171070ustar00rootroot00000000000000// CONSTANTS: #define MAX_CLIMB_SUM_ERR 10 #define MAX_CLIMB 1 #define CLOCK 16 #define MAX_PPRZ (CLOCK*600) #define CLIMB_LEVEL_GAZ 0.31 #define CLIMB_GAZ_OF_CLIMB 0.75 #define CLIMB_PITCH_OF_VZ_PGAIN 0.05 #define CLIMB_PGAIN -0.03 #define CLIMB_IGAIN 0.1 const float pitch_of_vz_pgain=CLIMB_PITCH_OF_VZ_PGAIN; const float climb_pgain=CLIMB_PGAIN; const float climb_igain=CLIMB_IGAIN; const float nav_pitch=0; /** PID function INPUTS */ // The user input: target speed in vertical direction float desired_climb; // Vertical speed of the UAV detected by GPS sensor float estimator_z_dot; /** PID function OUTPUTS */ float desired_gaz; float desired_pitch; /** The state variable: accumulated error in the control */ float climb_sum_err=0; /** Computes desired_gaz and desired_pitch */ void climb_pid_run() { float err=estimator_z_dot-desired_climb; float fgaz=climb_pgain*(err+climb_igain*climb_sum_err)+CLIMB_LEVEL_GAZ+CLIMB_GAZ_OF_CLIMB*desired_climb; float pprz=fgaz*MAX_PPRZ; desired_gaz=((pprz>=0 && pprz<=MAX_PPRZ) ? pprz : (pprz>MAX_PPRZ ? MAX_PPRZ : 0)); /** pitch offset for climb */ float pitch_of_vz=(desired_climb>0) ? desired_climb*pitch_of_vz_pgain : 0; desired_pitch=nav_pitch+pitch_of_vz; climb_sum_err=err+climb_sum_err; if (climb_sum_err>MAX_CLIMB_SUM_ERR) climb_sum_err=MAX_CLIMB_SUM_ERR; if (climb_sum_err<-MAX_CLIMB_SUM_ERR) climb_sum_err=-MAX_CLIMB_SUM_ERR; } int main() { while(1) { /** Non-deterministic input values */ desired_climb=nondet_float(); estimator_z_dot=nondet_float(); /** Range of input values */ __CPROVER_assume(desired_climb>=-MAX_CLIMB && desired_climb<=MAX_CLIMB); __CPROVER_assume(estimator_z_dot>=-MAX_CLIMB && estimator_z_dot<=MAX_CLIMB); __CPROVER_input("desired_climb", desired_climb); __CPROVER_input("estimator_z_dot", estimator_z_dot); climb_pid_run(); __CPROVER_output("desired_gaz", desired_gaz); __CPROVER_output("desired_pitch", desired_pitch); } return 0; } cbmc-cbmc-5.6/doc/html-manual/pid.png000066400000000000000000000107451301406513700174470ustar00rootroot00000000000000‰PNG  IHDR€à,Ö5PLTEÿÿÿ???___¿¿¿ßßߟŸŸ¾¾¾ ÿ |ÿ@ÍÀ°ÁÿÁ ¶ÍðÿðÍ·žÿÿÀÿÿ€ÿÀÀÿ pÿ `ÿ @ÿ€@€€€`ÿ€`À€@€€@€€Uk/P@Ý Ý”Óî‚îÿ¥ € õõܸ† ½·kðæŒé–zú€rÿEð€€ÿPÿ“ÎÑÿÿÿÿ‡ÎëÍ€p‹ÿ.‹W"‹"ÿdÿÿׯîîÿ¶ÁîÝ‚àÿÿðUð­Øæîð22ÿÿÿåååÌÌÌÀÀÀ³³³™™™fffMMM333@àÐÿÿ¥**ÿÔÿ€ÿ@€‹0`€À€ÿ€@ÿÀ AiáÈÈÀ@îîÀÿ€ÿÀÿ   ÿÿÿ6Ã{WtRNS@æØf pHYsÄÄ•+IIDATxœíÝ –¢8Eá’lÎeô‰û_Âð£–I| ¹ß9m3–¡«ï( Hýw„þSoêF€"@H ¤R)„BŠ!E€"@H ¤>ÐYoÝóŽiw€£Žhlwïú_“¦ëtQ7 59àÍõ7®î¸áޱ7u9`cîÃ;ïâð±ãÚÅíݲˆSŽè·w?îv¶œ Ðõ7]kkP“oÁ/5Î<0‹àË$ÄšÕ?itlBÛÿ&|º s[Üy{ ÎÿýlCþ›ðéB´ù¹ó> ÉÿýlCþ›pæPÜðÔÝÚ2Lþì¯È`òß„$'#dðÇF.R)„BŠ!E€"@H ¤R)„BŠ!E€"@H ¤R)„BŠ!E€"@H ¤R©«øï!ÁS#¥køo!ú“#¥+¸èŽKs_›#Á²”à[o$X’Ò\ËQx€•F¥(;ÀÌ(° E¸¡äw£À”àÞ§Àìà~_˜¿¢ xf®Üƒâ¢ÀÜ•`Ø£(0kÅZæ­àƒH+5ÀYQ`ÎÊ ðÈcI0[…x,) ÌW±}<æ©Ì÷D™*5À¾„sTd€ÅDY*4Àï}Ò*1À_Ëx ÌQ™~úu˜ü¼# ÌOüõÖ=þÙøÑ±1÷œ¨ˆ³=@c»{×ÿuÍcî9æ&z€7×߸vºãnŒ¹ã\C˜™è6¦¿1W¾Ö}0掓%+ðßoi†¹šèÚÅí½i­oºƒcn;ý7··ìþoÐ+‰ _>­½™»ix2À3_==C”öKäòÓýOaü´ŽÌ8Àó ~ôWxú/ëšÒ¾OÞ–aV–fBý‹öêõùW>D؆3NeNn„ÿ— À—IÈÄþzÈ™WÀX»RŸ|÷âþåc”hæ±üb‡»öؘ›¢ýå ‰öÒH´m¦;®< ‰Y@xOÄ—NÂCq~ºu&nUñ¶›XY'#Dï`#®Ø;üXUZ€7ãù”ï•ÑÞ÷Tàô´ñ—¦¨“VA{…s3„TIòÞxAeu3„Bª Ù¼¢¢Œ»ÈBŠ!UN€ì^RIFÞ ä€!E€*&@v¯© cor@€"@H• »€UN€Ñ79 @H ¤ ]À«*&Àø› ¤ReÈ.àe•`‚Í@R©"dðº 0Åf )„T ² xae˜b+„Bª€Ù¼²"L±ÈBŠ!E€Ê?@æ —VB€)¶™ @H ¤²]Àk+ À›€\ ¤â謷nyÿmÄ,z€Æv÷®ÿ5ßoNÈ.àÅEðæú×Î÷s2ÀÃ[€’D°1÷áeïy·uïC f¡×Zï­mÙþ »¸^  °k¦òÌÐaÓm}…_>íøJx&@v¯.,À—æºfõ¡/OøxÚñýø\€áE‰¢ï.ß‚ûÀµ!ü ìÙðÊB87 ñ¿Ç 6¼ºà~yïvžpZ†¹m  »€—`ãú»•ã¿L ÑË©ò©ƒŠ2Ø¿vÞÔ3Š{>’ñ·àýÖþDs//<@×5máæL”1° x}Á:ÍÎcþ ¿ëËú|@¼>„TX€ûç Dó^_X€Ã9ñ" 9HÂß‚ãEàù±¹cû€C„ÉÇœ`rž„`ެ®žÚÌVàÀ‘o9#À 9ü¥1Ÿ˜× ül˜x œ Yø>àög‘"ŽùD€5°ûú$„kþ|‹öL€˜å; aR…|'!ôW…|'!X…ð·àoOB° ù &À*d s:D¿8Ñù1'ôW‡è—g;?æ„ëý•çÇœ`2ÞL14rC€Ê5@&Á•È7À##;)„TX€~!ù˜#¬DøÙ0Ö™»éo“9`R‹ðóÝø[÷+#Ð_-Ÿý·`¬EøUò§#À_ºD/Ö"üSq}ÀçE fáË0]k½mc|2„1ËsIp5r 0ŸÈÐ+¤öoÁãìJ=æ+rhâ‡ÛäcÞ °"á ÑÝøàï,D`5-D?¥óN€9t(îù ÓŽÉ$¸&Çö¿´Mõ86 þÒB4Ö#Ëu@¬B*Ë…h¬GŽ ÑL‚+’ãB4ýU$Ç…h¬Hü…hgýðØùN{tL¬Iô…hÓ?¢{>Ê5Æ´o fÑ¢o®¿qè†Kë›·×LÄ,ú:`3$j]: “àšDÐ.n¦¹“þjýCIþõi[ûþn³ÃËÜ+ðW€ÃKàïy býƒé¿ß‚Wvw®qD€µ¸ØÕñKs¼MBÞ¿dû)˜ƒT%úʼn¦e˜ÇÄc|Ã~û¹"{+ ¿<›¿]žmZˆ~ì)ÞúIËÑ}@¬Jø[pè5*çCqÃÃný·c'ˆY~'¤`URŽ'Áôo®Q~jõæ˜L‚ëàxzK7LCÚÔˤ¿º„8~d\9ý³Z÷Æ$Àº„8.«L‹{©OÉ'Àºþœá¦u_pzL¬ËWÀqAïýì¾Èc`]÷»áPÈðO©¯’Ï$¸2³àÆLŸîR_œˆþ*¼èÝð»u‰Ç$ÀÊäv$„+C€"@He “àÚd`Š‘/„B*ðXpèùøgÇ$ÀÚð ©¼d\àMó…·`ú«Np€íínM꟔D€Õ ÿ\°/zöt,¬Î‘kÃtÃuO“žJ€Õ ¿6Œ?•dØDLÁÞ3œ xKùÌ$¸>áË07Û¿ú&ÂËÜðü“£,Y­`}R¢Çßx FTá׈vãoI× °>ѯ}bL&Á _œŽÁ¥¼2ýU(üÑãÏ éìÛÏ=Š7&V(|ìëmÒ T`…rZ†!À e se`ŠÁ·à T¦ÿPÖˆW@H ¤Ž IxB*Öèh€]²™W),ÀÛ<Iw$„þªtød„dc`•ÂOÇŠqnkL¬RøÙ0©Ç$À*صÎ…Þ“9HÂ÷ ¡¿:e³M€u"@H…hZëŸMJ0&Ö)|bñ÷é'Æ¥“ëtèCIþñcÓŒÉ$¸R‡Ž„<mrÖ[÷¼Ó5‹;[cÒ_¥Â_Ýø`·÷ hú—Êù‡ºvYy×&@ÌŽí\¢w¸ŒêݵÓñBoïÚˆÙ±Y°Ý?26g^.àñ{ Ä,,À'"ØÅíäíb ˆYX€ÖÞBû·§ß”wÆd\«À·à® ½(Â[€¦ “þjuèÒ!/ƒooÁï»+ç4`Nny9lnvÿPÜïIÈÊ´…W@ÌžŒàìÞ:à´ óüäˆiWÞ¸ ³è¯€ÓBôãe¯[½¢/b}ðçP\ÿÔvõÖ÷1™W+|¼öfkLú«VôuÀÆ$ÀjE?òјX­}·2b=@»¸íK\1‹ ÿý´2 †8ÀÃO‹Iü¼:‚ ÿ@€u›CøÛÙIÈW@lJ´ sÛ1K´m¶F @ÌŠóðü7L‚!=þ@€Ð"@H ¤R™C`Š'GYR)„BJ “`ܵ¦xn†!E€"@H ¤d2 Æ@`ЧFiR)„BJ “`Œt¦xf‡!E€"@H ¤D2 ÆD`Š'FyR)„BŠ!¥ U<¨Lñ¼(BŠ!E€"@H ¤$² ƒ'Q€)ž%"@H ¤R)„BJ`ŠgE‘R©Ô:ë­û=&â)q€Æv÷®ÿõ:&â)q€7×߸öטˆ§Ä6¦¿1ÍË¿û—A€;ì¯È`òß„³ÚÅíÓ¿üÿØ_‘Á6ä¿ gô+ƒà$ƒmÈ0 ¶!ÿMHó ÌÒ¸6 ‚ÅY†¹EØT)ÎB´‰²-¨P’Cq@¨$'#¡R)„BŠ!E€J rep9¶ 9™’±ûI?¶öÛÐ5Þº­Äpõ$ý/y»¡6.þÅØÒoCטþ/Äm<"~€«'éÉËØâ#Ôýÿ²—cK¿ ã¹*ÝÖ;Aü•çǼŒÝ:É6<ùNw6Þrlñ·a°õ}ˆàÚ‚ßò2vÓZßhvFx:èrlñ·á¾³/?Àµs¤¿åel{3wÓ*¿õÊó‘ç±õ߆qÇè/p$=W6‹GÊoƒÙœ\ø-x’OÒ±…›Ònž-záIÈD¸—S€ºoÃvÉ–a4sÿ—±Çó´;ÍzÐ$‹µß†Ý½ÏT Ñš“ô_Æv­zï;‹¥ß†®Ù ᪇âütG»þ Pým°»Ç9R)„BŠ!E€"@H ¤R)„BŠ!E€"@H ¤ðs?? cçÌÓåÕ1´§Èæ‡Ï :éyúŠ5¹!ÀsB|½2?ÓâžóóÑ ?|¥ëo¼®Çã.6^-ÉõoÕã't2¸VKNðœE€}^·áÆùþ5Ï->8&çÝðñ »ìÂa¹"ÀsvÃÅ »ñÞ˜Ü\ÚX¢¾ */[™!à¼â÷“ãðŸ ðž³à0 6{

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. 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):


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

cbmc-cbmc-5.6/doc/html-manual/refinement.png000066400000000000000000000346761301406513700210400ustar00rootroot00000000000000‰PNG  IHDR±Î?±«F/iCCPICC Profilexc``2ptqre``ÈÍ+) rwRˆˆŒR`¿ÀÀÁÀÍ Ì`Ì`˜\\ààÃyùy© |»ÆÀ¹¬ 2 UŽ +¹ ¨¨ê¥¤'300ÙÙå%@qÆ9@¶HR6˜½Ä. rвùÒ!ì+ v„ýÄ.z¨æ H}:˜ÍÄb'AØ2 vIjÈ^çü‚Ê¢ÌôŒ#Ç”ü¤T…àÊâ’ÔÜbϼäü¢‚ü¢Ä’Ô Zˆû@º! A!¦ahii¡ ¥"ŠˆqŸÁáË(v!†°(¹´¨ Êcd2f` ÄG˜1G‚Á)Ë„˜I/Ãþ©15C}†}sïPoæ³åé pHYsttÞfx IDATxí˜EÓÇ‘ ˆˆJPÉ A’DáÈA2œ€ä ‚ ¢$•,^‰’3((9Qâ‘sΔT„#ƒ|?n>†qÓíÎÎìíÎÖ>÷ÜÓÛÓ]ÝýŸÙšêê /=}ú4†|A@"ˆ)8‚€ ¨OT¡‚ 1„'ÊC ‚À „'¾ÀBJ‚€ O”g@O|…”A@ž(Ï€ /žø ) ‚€ }bG~,ƒ,D¬‡€¹g, Œ7.…xñâY>Y‘ X s÷ÎK–#–G@x¢åo±,P<@@x¢`ISA@°<Â-‹e‚€ àÂ=Kš ‚€åžhù[, žèXÒT,€ðDËßbY  x€€ðDÀ’¦‚€ `y„'ZþËAÀ„'z–4Ë# <Ñò·X( <Ѱ¤© Xቖ¿Å²@A@ðቀ%MAÀòÆÿùçŸÛ·o[/Y  Xoy"´á†|öîÙ³mÛ6kƒ%«Ë# ?Îvï^½¦N OT1š4i’Z–‚ ˆ€NžxíÚµ¸ñâ­]·.~üøÊ²wïÚõïãÇÌY<‘ÍrñbÅR¥J¥*Q¢Ä½û÷Õ¯RA ЩOLž<ù©S§îÞ½«®ùÂ… ûöíS¿JA@D@§œxòäÉuëÖý0hPšÔ©cljÃʯ^¹Ò§oß@„@æ,‚€Š€Nžøøñã§1bôïßÿ¥—^Rh:tÈÔTÑꌥ ‚€yèä‰)R¤èСCÖ¬YÕ™,Xðï¿ÿV¿JA@D@'OL˜0¡Âÿøã;·o§{÷Ý7"?ÌYg,ô?þ|êÕ „„”.]ºXÑ¢»wïV‰JAE@§œøèÑ£¡C†|õõ×™3gF¥È‘ËèÑ£œ(Q¢B¦-‚è䉇lÚ¬Ùû￯€’6mÚ 6|üñÇ« ‹€Î½3áÞyûmí²_ýõ{÷îik¤,‚@À! “'æÌ•kì¸qXä( ~òäÉèQ£òæÍpë— ‚€  E@çÞ™Cf8`Ñ"EÒ¤M ¹ßNŸ®ß ºE-i) ‚€ pè”Yg¥J•fÍž]¦ti,Çß¶mÛ€[¼÷>sæÌƽ§c= xÄÏš5KÌøM½³«W¯¾xñ¢©C!qý<°R§NÍIK›6mrçÉsîܹíÛ·‚Æ ›6mZ°­Úõ®_·®GZxwzI÷xøðaÛ6möˆ œû¹×Ò³½ó¢… 9Ò­[·cÇŽõêÕK;ÄŸüѽ{wmåËÄŽÄé{ìØ±–_©Ž†¯^ùj‚ tô•.î °mëÖø¯¾Z¡bEwK÷ðŒ'!ñÑ?ÿ@›Ä×$¨Y³&%e°Ã‡=yŠt}vîÜI´´Â… ÑšÝ[*gnȉ³çÌq¯¹´Òƒ@xxx“Æ_~ùe=¥s<ã‰Õ#?PƒtîÒ%}úô*eLƒÍß9|ÕªæÍ›«HAE`Ïž=¹sç~÷ÝwÕ)‹ŠZR},X¸ÐX²B tê_}õU•!Þ¿ÿÆØ'Zï7pëæMâBÓéS§84`¥( Ôsƒ#GŽ„††íctéÒ¥ëׯ£ÕÂêð|¿‰åÕááÍ[´ZdŒZ¸ „W®\Y°`¶ã­[·Û m¥RÆ`¥SÇŽöõQS¥rå.;óKΔ)ÓÁƒ#""òæÉ37{’XðžØ´iÓÊ•+)?~œ#øîß~ëzÜõë×gʘqò/¿¸n&WA@ÂìïeÊ4f̸ªÀ¨ÅœŸ~üq×îÝ÷ïÝC<\¶t©Â€ýû/»ËŸþÙ3~ ­9ÚC®I’81v+¼„dâ¦O“q… :pàj“÷Þ{{¬(óO/^|Ûöí•*VüiâÄ¥¿þúZ„¦Ï2Ðð[o½µuÛ¶† üøã‹/N™2e  s÷XŸøióæL’$É{™3}þ)_¾< 1CƌѰó‡TSq©óÇ ŒR¤L3fLöÂ)#³•QàåÔ ž[Ähs˜óçGÙ>˜èFxé²e¾ùæÃ’%ƒ@k÷XNd d¥.]»",THÇÒŰUqsu­[·®\¹òG}„ʇ(w˜©›”­ÝÌ}„ëÖ«W®|yDò™3f¬ß°At¸n>ˉ ݤI“æ×ßœ8q‚3Y7‡ôçf{÷챟žûO¡}_ËÔ /F/¬]Ž ‹}AÛÌE9Mš4œŸrx'wî{š.ºXû@ííUk´Í\”‘Ux¶¬Yoߺ墥\RˆÕ³gOõ‹ûΚ5k¶xÑ¢˜mLjÁ+ˆ¸8¹rçvxÚŹQ¸KGR»?„ï[Λ7ïÜùólèÔ¡{÷êµbÅŠ¥K—ò°®X¾+YLs° Ûµs'–šj3Ë`ˆ}ûôAuˆzKY,€”+[öìÙ³X Ì›;wÇŽ1ž>åŒ~Çöí¼/säÈá>&5©c‡M›6¬Èü ú÷ë‡B6gΜ†#\¥J¤÷Æ#6¢õrÿÖiKÞ<:>âœ:yòæÍ›j_ ¶—,Y¢~ÕüÿÜùÁýûíڵ˙#¿píÌ¥ 0¬²eÊÔªYÓT4ðšç´ôî;¦ŽâŸÄyµ|ŠÁÔ“âùóç§K›V1°õOüdVzô‰¼="nÜ@dࣾIoFD¨_¥pêÔ©°yófΜ‰(ôÍ7ßÈ[T½qÇܸaº>‚¯ ìÃY½dFaøðá„VÊ“'ÏÞ½{qã5c£© eJuëÖM—.ÙÓƒ-V«V “oŒ½Låf/Äú6ש[×n`°Å­[¶Qîø‰–GØ»à°Î3Žžy|ÙR)\¸d‰8;.,c Ùâ´üüs<.\XNÜxñb„•HýÃGŒP½tøÅúöw8 ~f‚_ æ´h„—-[F¾I߬Åõ( :îLUiCf Diã>b>n©“'2ËÏ"?¾ëÑ£b¥JDmÃtÃdz×7:Päy(¢§7;¼äËÊÍ›6¡íugDF¥™b»ƒVQ \æN_û6ˆÉ†Ð±§¬ÖôêÝÃXõktHl B]sðÏquîÙ,\M6«Y Ò¦MëŸ+´ŸU§Îûôík_/5ÏDÿx[\¼tIñEsqSà_Ú«o¾ù&q<Ñt+•ȉS§L¡lÓìÙ÷矴åÈžÎèhÇÒ]æ4òì™3Mš4ÑMÁ¨ŽK/.\¤ˆQÔ¬DG'O$8ئ͛µÍÙé< }"¶»wnßþðítZË3ÆI–£†p‡Î½{÷þyø8..£ä,(^¼x½zö<|ø°ÒrÀ€ÇŽGYL£‰'V U›}ÿý÷„,;f òÑä)SŽ9‚Ýåܹs± ˜0a†C‡ ñ’‰]fOÇÅL<º„‹NÆ =êbRc{X¬IÄ›lä[Óãhyæø¯ö$Þ®ìêWmÁ¯ÎÑÁ0@;=)+`?à'‘W­Z¸P!Ý÷…W5;ÝÝÕŽFÑQ ²»Êž-JOµ&º ¸gÌ!ºF÷óquê #xâøq &ÈÂñÊ+¯ðZ ÞQû¯¾òó÷7ƒ(gœ ùù<£ez¾Æ+)Z†ÖÊî’¤.[¶nÕVzTÆNÖSY£è¨“ÿᇰvÀ0P­‰–¿{~™<9ZF÷ÿAuòD¢"³é@U¬F×xãÍ7ÁÚ7 Æ4ô>žÇC‰o´?”žNÛ7í9zÚà€oÆr1 Q[^(çu.biÆôé -²¯÷q f˜Ø(&î>: †Óɱ` V±pÔEb)†q¬úÕðĽÏ(í'¥áàxOSÓD‰cVå=)o(4kÚ”³b4xCÄ?û¢ôD_íG‘ÆG¥~âäIÿDÉf¥“'nHeˆŠÔ–8òcÞ’8ÃQt"’W®Ì&‹ÐOx³»9¨C;ÚJ7gëãfèXÛ·oïãAm†ãçJ$‘={÷ÚÔ[ãëСC1Y‹Þµª\™ ˜ªi˜óƒ”Q¥wíÚ嶲Ƃcµ9sæ.>³&o¢bÆð—dSU¢U®lœ‰Tf¸tFZ|öV‹¶CœA¸Zõê£G®P±¢ÃR©"౜h”Ô¦ÎÀ‚÷¥]'Î6î lmF n¸ûíúuëzôèš A¼§Q°T@ ,Ö‚|%¥mHr€„hU†È2‡±q6šȧm›6}ûöÅÑV‹¶ ²‚0¿|“žEÊØ´É««ö¾à1ODj#8†²o½ý6‰î”¼7nÞ®]3˜™{€øQøár’ƒÞ’A1O:µbä ²qv†¢Ñb´\µô¨žì5ªW‡!bĺnݺ±cÇÚt_°`IPñüÅ„€,†ËP6ÃEïWö(}ûõ3vD÷!™—"÷©hk‡aò¯5GILÙ­°vá^–=扌ç½Ô¦cÒü´È(«Ì¬Ù³éŽÄ7|ذ/[·æWç53JwÆõÿ60&Ã7Î'#¹Ìž3‡åã>UªT… ¶bîœ9Äk`hÌS¬ýsÅ—·á{|uš4nLê-ÚZaˆìÙñWAB´6ÂÚU{_Ö©OÄ6s¤6f»™øÓO¸Ly?Ž9BjÀ ?þ¨´a->ûŒcJ]ÔKˆB(@ (Uú]˜:uj½zõŒ]nsžJ":í4oÞ܆>VÙ0D*1õoP¿¾²Ë³ic™¯ .|/sfc—Ã#MøH‚ãBV‹¶: ŒXqyä‡I(Ik#¬®Ú‚Nžˆ)Š´÷;vìhѼ9[‚dÉ99$BFiÂèË((¤F”rH<˜+±½/S¶¬ø±áŒVë·Ó§éÎ#qñÂ…ÎêððæÏsïñ2C«¨¥açN”²£X>;دK–´k×N‹€›e£E?ËŽ RZ´Êlª:vè ”ƒa7ñt·/Ÿ $Ò±}»vÄ”¥€þÂ!)CüÑyœ “ev_~ñÅÉ“'ŽhSI,åiÓ¦ÙTÊWà&æ g“çänP%Ìõ|@ÄrüÉy© 6@líš5 I8ææÍ›µäX:uì˜.mZÎܼ}ÚîXΚ%‹Ži»F)ûòåË Ymå+! ¿ÿßÿ‚ aðºè¢GŸ»½þ÷ßJ¶{äÄÞÿû5Xüûè‘»œØóv¼•ŒÒˆŠ(G._¹‚#›Éöˆ^«V-ÏÇ´~ÂvÉDÇ: 7vÜ8ržõ06„{Y±r% ¿Y_J>;„¶ËF“ˆ8ÉéÜ’%K²eÏ®cÜ€ë¢Xá蘶k„‰1®ÒTÑVj.ù±Â*FtòÄœ¹r5 “+Þfx§¢žƒà²FMË!}¥y!ðx‰ŽÙ!¤$©ã¶#=ÞOÜ}6 ¨‰Â6E¡}3m ¯±¯ü>VˆvÂ^–'MšTÄ‹0…:FMÄÙ£—Óæî:õ‰ÏŽ8Z´Hž,ÒgÙÒ¥DEfck6”JFiì0@ýûúu2JG9¢(]@¤[™¨ÐL‘2%wŸ8 Jhk |\ „—vlß^¿AÝ „uC§»£N9‘ñÑ^빈Ñê‹/tÏÀýŽ˜‹ãþ…þXé’-[¶‰“&EÙ¼1Eÿk-e—ài˜ÆÇ#•zî¬Å·±¶Ÿ‚°;°{ÓF§œÈx&ôéÓ‡”Œ¨ØÛ¶m«Øåx3×}‘h”ŒÒL&ªÇî={xýº&E~”Qì]mÕ«˜k ýн:õÇi_ÐMÓb9—÷Fic¬Zã(~˜h3\4K®Ð/'víÒ…´½zõz)fLNÁÚ´nM”Jož×Åq¥K—.ì°á4o8†Á¤¬tÝ‘5ª.×m‚óê¢E‹t#ƒ™n*˜à7F¸á¾6/,ìÒÅ‹ˆEõë×NHmVvUÉxeSïÎWÝ?úçÒ62}üøñ8º¸3–´ù¼yt|°À QÛqïÞ½¦æ ²76„™@îƒs¶sèСùóçkç`_æÁÂFľ^j@à™‰ÒÔ©…y~í믾2¾ ʘ“½z~X˜‹6rÉ!:÷Îì”mr"˜j+£ûÉS§pãài”ŒÒ˜†„„ü‡ÁÛ}Ùºu«îµ1«U´äƒ|ù¬¶*ZÏýû«~üq´Ì 9¢æôèÙ“Ÿ D´Ì!@ÕÉ3gμeËíš ÷þóÚzËØl+©T0úÁÉï×¥K£ŒóèŠ5œs°)béÞ;[ óÖ‚”€¥„yô]SÆ(w2mK )溽\Uð@ŸÈ>ß8 ¡1Ð7.5Ož>+ÖÈQ£Ô«†}Òĉ¼u“$I‚ý¥Ý…—b[îNã`k#v3fßqxbÖ¬YÍÅ5}l3fΘQ¼X1¬ë1&uÝX®‚€<ND&‡:uëâœ@Ï‚vø"w¿Ë$X•ŒÒxæÂ•!Øà97^<#rTÝOÒÛ;ˆ#Qn¨£+Rg~òÖ©[¯^Žœ9Qs"Ú°Q#ÖgQBðDÀÎÆ‘Heñ¢EÜG¹“õÃL™2‘i ­¢J}þܹ²åÊ©5öR§'•8²ö¸DS1Ö2ÑÑ A]‡þÞÖ1ïºõëK–(Á”„-º¾/žñD†ˆ·9 ¼ÙÕ.R„°]x•”+_Þõxº¯êË(í›ÝK6µãôîâsb&Ä„Ãð«ó=Ô‹°Er²gÌ”©@f.=°i{ƵkÕçU¢¥àQ9z3J{4Õ€h¼xñâ&Ÿ‰æM‰ÁOöÎêa‹C†­[§ÜÄtQ…Ŧ “'ª^%$J'iEIìŽW‰ÍðîÕ—QÚßJ÷×kvK¼ú^‰ßìQ‚™þÕ+W”H¿O¢»O0c'†sþ·fϞݼscçìšN-»âU‚޳êU²eóf‡cRi“Qš€+ &A†"‚€á8Ò?ã¡áé@4ÒÉ¿übà’'Ož¾¤_NôåD£%£´/(c >F€\›¸Y‡¬/D{É—?ºtéF`|}¾ÿ^-9R'LߊåË?oÕJ‰¨üç§JA…,mˆÍCì¥êÕ«SCø²ãÇSpFÇÅd|y)0x"ˆ¨¥9n&£ôÁ¸%)R¤ð%XV‹˜MXiE²“ÀªQ¡L²b|4–zîüyj`mª£­‹¡±¢S®ÆŒ‹»l}t\ a쥀á‰Ds $\«V­NÇŒÙò³ÏðÜDÙÁûGI¬n,(Á@  ,,Lü‚á^;\ãþ}ûÜ4ŸTýâ·œg.¶©R9¤éN%:GCè¸3–¾6žé1¹:ùŠÐ7˜7½á‡ ŽéÏìY³êÔ©S¹J•o¾ù†PHÞÐ æ¾ØLðÆfÌ^ûk ÞºyÓìQtÓÇ·FÍš®»Û¸l³WCO\g¥râÔÈ#›f1øþ| ò¬ -GötFÇõd|vÕžH$•±cƯ–É!BÛäЭ[·Ì›7¥9ƒ>¥•H¨ŒeFiõÞ˜71¡,8D€3VŒv^ŠöJ~¤mÁ¢ÐÅLØ™ 4Ûš^={*¿z“$îØñããÆÃXxâĉ•BCÕf$J"¼,‚Ó“§L!#Åž={æÎ‹Ï¦ÄO2jœ—ÂIì鸘‰¯/Ž›@$ÃzYڳ h;9|˜ˆ¶F-s8Õ©cGõ«¾8öîÝ{èС!ùó“dšíÛµÃxÛ5µ éÓ»n´WGÅ;?h—ãÑP´H ¤cˆÏ[¶äÄCGG¥ ‰Øâèî®v4ŠŽJЂúDx<̈`®Ä"ÎþɺÊÂ/_º„ŽOýjxy›ŒÒÖ¯·É(; K3)IDATÏŸ‹±ðwFz%Ž™‹6Áy‰à(wïÜ ÎµûfÕhla¦ŽEvÜ[q `τǖ.<ðˆ ‘ÂÇÎÙÐ8Þ-_¾|ËÖ­ÎDYOdC‚E'Ê {ÔÀžÝvíÚ…Vª„Åæë×I(ªM‡røÐ¡Ç.ö=š–ÃÆ¨f=Í( 7db… vH0˜+_O˜Põ fÌ[;¬ÊT-&ÐĽïÛ·/‘À²G¡¡¡ $Àl- žX¬hQn›äaaž>£ìOdZ˜Ió‡>1g®\Zç0ø£Ù)ž¹ÓC† Y²x1OC±âÅ¿ûî;ìr\#Å ±¤žhRþá‰ö°[cjX&ü@ˆ÷U¡bEæ¾z5©eaˆèÜ1±;v¬³…4lÐN=}Æ g ¤Þcž¨@ú CDÃzçöítヒ­&SÕ‘Q:IÒ¤W®^5uVKܵÉnà®ËfŽËß×®á¿aÆ”8åhÒ¸1‰@¸È‰³çÌa”;w¦J•ª°“Ñ„ñãI-ÇÏŒùX†¦NžÈú1Êùª}{Ž–(c;¡Ì|`.œê ÚÔ­[W¢lÙ²$_·v­ëÜeJ—F´4oVMÙÔ_l@#cÔäÙÇ`ŸlOä0aÛ¶m¸Ù1U~ƒdV uÃW­jÞ¼¹ÃùÃ9íݼe‹âpâ°T‚€¶8Z¼¿9Yÿêë¯÷ë~ß¾ÁC†Œ=š£amcËú2Jc“ 35v&–¡FØŽXf9~¸‚¨Ö|:¦‡Q ¿)4E¿EÚô°'»xá‚BË\4†ÊÎŒô™Í[´Pê  VÑf,hýzõø…nÚ¼YÔˆ6àØÕ)':x°i³fJS(¢Läö“€‚(¾öcRÃùñ‰b«Rs'£4{g¢©]¤ E ûûï/Z¼øÃR¥´•R6Lñ¶ÒG13—/_~)fÌÇÿþ[¤hѵkÖÄŠÌ 7dËüYË– e^üùòå£ÌésÛví°ÆWê±üÿ!!6X[$D×ÿuòDŽóm×òÊÂRÇõ`ž^å±ð>£´ìÁ^¥J•¾}ú8»*õÞ#@Q¤3}txnÇŽG<.ò2óËú¬E ¬ÐvïÞTOÄÐG%«fŽƒQj5‰XÏ›;a¥qãÆ»tQÛKÁ5:y"‡Î#FŒèÖ­/.€yaŒQ»ëÁ<½Êcá}Fi,V…‡«ŠHOç`áö%J”оr,¼ÒèZZ®\¹TaMßï°›AźSM|BP£»Ijîœ9ÄkÀº€ ¯nv‘f  “'b)7o^ÌôÓ¤M ôõ40#;Š÷¥y¤ˆh$<Ñþq'/³‡ÄÏþªÔ…€7GÏ)R¦D2À¦G »@;ƒuÂiyöìÙõëO›>Ýl³wfmtž±°¶J•*Íš=›ƒÝ‚ âó×¶m[3¬î âœíàÏÇy ¥ÿ¾~ŒÒQÚ¦M ¢lœ 8fÁ<8×î›U#:¸°Ô1L¢ì…ïVçç¾Ì(ý«×¨ei " SNTú“±“•–Ù}¥å˜ÅÅ})R¤È/¿ü‚¼‹6rÉB?úhâO?}Û½»"*û³/¸ CDMŒÒ }ñ_~™1cFå’=^ñD{ræÕx“Q:Q¢D;wìÀ¼Ñ¼é(å:u뢼ÐÉÄ´«U«F\SE­k ö7hí‰1³ÿþaC‡Î »tñ"Öˆõë×wJóéS̶—,Y⟙TNÛo. OT2J“ü¼ÚXla ‹ÝæûDÛŽLˆn$<Ñ(ÐEˆJÑ£j”¸­:TЍ·Û©5ÚµoåÄH…xe3ià ýúDgMª÷&£4Ñg1ú7ibNVTŠfßA!ãÔ`ö(Bß(†'bRsòÔ)Ì Ð`zš'wî:µkkó¸@DQ)" ¹h´—•bÐ.ß ÇæaËæÍ>H†0—Tõ­—ä~ûí7Š—(aOk€qcÇö0Àþ’¾T-¯"à`ê&…K–lùùçµjÕr³}ð4»ö×_¤d#xrð,ÙÇ+EÕ“3GŽã%˜÷ñäƒp8ô‰p"òº:Ș²=ÍŒ)«U ¡mµ5Q–qÅ^x¢=PѼu(¼ìIICP)’ßnÑ¢E;l •~…€<Nôàþ}2ÐãBd¿B·%rÚ÷¾†ã¿ž=zÈa‚C$K•*õ]º½ÐÒ”J-zŒ1Bx¢¿-{ÀYC×nÝœ h>ˆ)ë ˆ¼« hFÈía$iÛgûz©1 Ý9FM@踀gg,6 ‘H›6mb°cÇŽ!<úyªeìú‰ã§£GãÙÔ“'ÇE¥èCêx%“PhòäɆP"¦"àOÔN¥w¯^„ù?n•wPxàß»•+W&e‚œ>ko¢ZnÒ¤IçŽÕ¯R0o:t˜4q¢ád… áè䉸—'K–,lþ|%m6Ô8ù‘ùÄðùK»“.4ɦ]»v=2ÀÑE©3êÕ« Q^É@i2 <‘ÀÕªW×Πa$óÓÖøayøðáK—.õÉùÔˆÀ,›;So„¼’M…×(â:ybŽ98¦$I˜2vÍú÷ÿ 2دQ33ƒnO|HÓcñ@§‰)ÕˆáÃ}þ<y%ûóÝQ禓'’jùÝtéòäÉCV–Úµj…äÏÏVZ›ÚTÀß :w&ÿŸ¿ÍÊæS²dÉ»÷îÉI‹y÷B^Éæak e¯üXˆË@2Ù'-VLÍÍb?9ÃýXì‡ð¨&ó{ï1ídÉ“{Ô+“@}çöí /†ÅFËyð¾‰Ìì-£Ë î à™}¢J‘ˆêœ¨™& dCuÚJvNŸ>ݦ^¾rÒ’)cF±l7ïIP…q3‚Ò›7í ¢¬sïŒË n!óçÏ'UXÀáõ]÷î»wí’@‡7Ž$Gr4ï£*5j$fOFi<‘ Äô'ƒâ´©S'MšÄ1´“3‰&j’´È/ß!¼Ê9€¼0‚cH¥bö$¦DtòDØJ³O?%œ/f‰ 4 kÑ¢¡q̘¢4å—ï UîlºtéÈ¢é¬Ô{vl 6ôžŽP0<‘„³$| RÎêÕ«›ú)N,‰%zå•W̘¢4å—ïÕ9sæŒ3FyyiÀ€ä„½„Ѥî:y"!á¾hÕªXÑ¢˜%~XªÔ¶íÛûõïѯI³4ƒ¬üò¡*/ gÈXÿqµj"*ˆ§¤tòD’ÌÆŽgÐàÁá«W7nܘÌÜÎÉ7¤øåG©U¼uóæ… ˜ÏéS§8Mºÿ>Ñ.ü9$šQйóÂ@‰|ýúuÞŽd÷f\²)Tب Xž¢")˜]‹Š‚p´<:í±Å9x𠛦üÍ>Q–Ç1 q–ôLihÖÒ¤N}#""mš4W¯^}ððaéR¥ŠU"V-ÄæÊ•+Î,–P›T­RÞ—bÆ|üï¿EŠ]»f þ#G*V¬˜U11v]:u:óûïsæÎuHVv‹/*‘ztÈ$»qãFº £3:gΜéÔ±£³«Ñ[ß±cG’yº˜C•Ê•»tîŒc¦L™† ‘7Oí-séfDÄ{™2¹XÎÅ‹yO,nåÊ•p€™6mZ÷o¿uÑE.Ù %sæk×®ÙTª_a _tîáÖ+Ìá†-̸ñã^R++T¬ˆ”$qb ¸K?zôH½dẅ(Sˆ 3Aÿ4iRBgb½OáÞýûÆÄð¥=vŒ˜R.È Â.À1é’Nž ±ÂôˆÉ‘ÒQ-è£c½^)R¦$#Ê唑Qàc½eFãŠa߃¯“'h¬0ßãl#²Ç ¶%ûx½‚°Ù€ëä‰+Lšò:ÄM…žఽTzŠ€=°j§¤¤½ûÄêÙ³§û­Õ– $¸pþ|£Æ÷ïÛ·bùòþýúáÜ^¾Bµ¶À¹é˜K—)£­ ˆ2:Ó+V†–C@–ŽiζmÛvíÜIØä€X‚I“reËbQð×_Í›;wÇŽ1ž>åŒ~Çöíhyeš4nð„£ë^ë´ÅQ¦ ±Â¢ kWü±Â”…qÔÈG)ãìŒÉnñ%üÍ2CA@œ!àOD˜¯W¯ž3B—/]"x½³«R/‚@@ àOÄêâÁýûŸ6oN*gûµ>tHÀö°H ðDÖµ[7›´÷êjCBBþþûoõ«A@D<ã‰Î"+̈÷z B sA@E@§}¢Ú_ ‚€ X á‰Vº›²A@ðá‰Þ"(ýAÀJO´ÒÝ”µ‚€·OôAé/VB@x¢•E¼E@x¢+ $îâ²ë«.:ZãÒíÛ·-äñãÇÄ]wvUêÝD@v(c› OtŠçÚÈÓË1bwaË–-.XøÒÀÉÉãlD–=z´‹Î:J½Š€ ¬Báã‚ðDÇ€“ŽŠ€`U«VU.“±oÛÖ­5ªW'oŸÚ!44tóæÍä®Sk‚¤V @”)S²^2ÕLžDØ$qÕ²eË´pIÙlæ•sêÔ©Ò¥Kóš¹qýzÛ¶maw`ÔÝFx¢èHÑùrœ8IßzK½Ö aC²ž"þ¨5J6<¦¤^³©·ðWd–*Uª¨ \0þÚu딯äðÚµk×¹s甯+Uš9c†ÚR n"`ƒpâD‰Ô½ÈÛï¼sG£Æ„]@ÊæY¨cÏ?žù;{Nÿÿ{ ÿ³ýÔÝÝ—_yå•%K–¨q!£ºxñâìkêÔ©£m‰8É’µ5X&[¡} ¤Å‹6L]NË–-S§I£|/5ûš.mÚ³ÏOµ—QëðÑÖP†{&O–̦Ҫ_Šã¿úªv;Œ\Ó¯_¿Ê•+Ÿ9sæÀ“ùE+bN²äɭІë²G+ô3ÊX¼^Ž7s–,êЂ° …Mžˆvۦү Tªtéóÿ剳gÏ0` qâO?!i®>ìþŒƒÁ­ªt©Rªµ soݺ5Æ›d»þ(46¦‹ÚÍõW¯fË–-ЖÍóµA¸ûwߨ¿ÿô©SÖ¯çñCøèÑ£S§L9~âDîܹ;}ºc‡{öìAûÁnSüøñã³L<ý‘Ö­['vl´Ã|5kVDDÄÝ»w]²„<œs4,±¶nÝŠëHÖ¬Y‘*ØBýðÃãÇÇ% •èã'O’'O¾dñbŸâ¼ü²jâºtéRÆBœ„8jÓ[7oŽŸ0aåŠùCBtËæÍ¯&H€iº‚öòåË÷îÝ{í¯¿Ø}§OŸÞÞÜݘ›â‡²«ŸL ÝÇŠåË]Lw\2\4°ð%ÒyŸ8qÂÙ‘"á‰Î®J½;øaÔDcÆŒÁø‘)¡â5—:ÌŽzdF*gΜ١C œ5lÐà÷ßç™ïÝ»w£† ·mÛFÔܱ¹úå_À )`|Ê% | R«fM¬Í)À"©!¼º¦)‘]øúUûöìÜŸ5}ú´[·nüÜ”0+Ì?zø,3É›'ÏéÓ§i°g÷îiS§F¶}Ú¯o_” JÙðÿφä#A‹\Iበ‚ÁÂ4x·eÏ– ­¥òuúôé@¢L¥Rù·Âý†2†Y WUꡬÕ'RÙ¦M…'g=»ÒŒÿ¼bóäέ°N( 9*—à¡È’”—/[Ö ~}äDÚ ½1O›mcÄm¡"X¤BvKì¯Ï?Ïêà•I’$Q–™&ujíz?úè£_&OF½NžwêaXʾ[ÛÆ¦¼sçÎdï¼£V²çÈûÌï¿gȘ‘ÊdÏíÛbŎ͸Ԕ-WnÆ °Eø#¬ö[;ŸH•”—9cñ@é.XtvŠÑQN$ʧI“&5kÕRV‹õŸºlLÓ>®V-gΜ„ŒShMphioƒu:¬S%¢8ƒ½þÆJ §1ê%¥€Ú·_¿ƒ‡Íž3‡ý5zI›F}žh’BGLž>Eƒ¦L‹q"Ç ÅÃíšÿ°­òå˳¹V®"¯q CI ÅŸºZö³D̃uRs!R¢ä꯿þÊ×7Þx:.=wz¶#Žì e Î9«‰üƒón¶ÒI“&U¾>oõl0¥fÕªUœº0=N> u3V,¥Þðÿrîl8¤BPöíÝËi1k_K˜0{öìH7o¢@¼tù26:]+Z4lþ|6ÑpIÌ‘á€8¶sH}ëöm"qqÄL¼Ü Ï={÷Þ=ìù ÕƒTX)4Ç61à 7Eø¨Ô©SÏ™=^yõ?85Î!CÞ¼yGõðÁƒí;v@öû>}Ð`b”În=âÆ,Y²Ì›;wUx8:JÌw®\¾|ôÈDK"Ã@Zµ²ªˆ¿ô‚HUH ‚@À"À^m ™º2ŽÁŒà}j}6œ\+^L=‚W*m¨ä’Roß‹\E‘O]½)½`—qãÆEçAUœtHÐËJá‰^(ÝAÀRˆ>ÑR·S#^" <ÑK¥» X ቖº²A@ðá‰^(ÝAÀRO´Ôí”Å‚€—Oô@é.–B@x¢¥n§,F¼D@x¢—JwA@°Â-u;e1‚€ à%½Pº ‚€¥ø?ýQýWùD<®IEND®B`‚cbmc-cbmc-5.6/doc/html-manual/ring_buffer1.c000066400000000000000000000006601301406513700206750ustar00rootroot00000000000000#include #include #include #define MAX 1000 #define SIZE 10 unsigned int sample() { return random()%(MAX+1); } unsigned int ring_buffer[SIZE]; int main() { unsigned index=0; while(1) { unsigned output; output=ring_buffer[index]; printf("%u\n", output); assert(output<=MAX); ring_buffer[index]=sample(); index=(index+1)%SIZE; assert(index #include #include #define MAX 1000 #define SIZE 10 unsigned int sample() { return random()%(MAX+1); } unsigned int ring_buffer[SIZE]; int main() { unsigned index=0, previous_index=SIZE-1; while(1) { unsigned output; output=(ring_buffer[index]+ring_buffer[previous_index])/2; assert(ring_buffer[index]<=MAX); assert(output<=MAX); ring_buffer[index]=sample(); previous_index=index; index=(index+1)%SIZE; assert(index

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.

cbmc-cbmc-5.6/doc/html-manual/satabs-background.shtml000066400000000000000000000143101301406513700226200ustar00rootroot00000000000000

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 XY summarizes the concrete transitions x1y1 and x1x1, and YX corresponds to x1x2. The behavior XYX is feasible in the original program, because it maps to x1x1x2. However, YXY 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 YXY 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.

cbmc-cbmc-5.6/doc/html-manual/satabs-driver.shtml000066400000000000000000000215701301406513700220020ustar00rootroot00000000000000

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. 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. 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. 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. 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.

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. 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).

cbmc-cbmc-5.6/doc/html-manual/satabs-tutorials.shtml000066400000000000000000000010001301406513700225170ustar00rootroot00000000000000

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: