Skip to content
Snippets Groups Projects
Commit e5154847 authored by François Bobot's avatar François Bobot
Browse files

Add Farith as "plugins"

parent 895c2501
No related branches found
No related tags found
1 merge request!3Start the COLIBRI manual in the website
Pipeline #36983 failed
Stage: deploy
    Hide whitespace changes
    Inline Side-by-side
    Showing
    with 15 additions and 1312 deletions
    _data/nav.yml
    + 0
    − 6
    View file @ e5154847
    - name: About
    link: /html/overview.html
    id: overview
    - name: Features
    link: /html/kernel-plugin.html
    id : features
    - name: Documentation
    link: /html/documentation.html
    id : documentation
    ......
    _fc-plugins/acsl-importer.md deleted 100644 → 0
    + 0
    − 185
    View file @ 895c2501
    ---
    layout: plugin
    title: ACSL Importer
    description: Import ACSL specifications from extern files
    key: specifications
    distrib_mode: proprietary
    ---
    ## Overview
    The plug-in allows to import external ACSL specifications written in files,
    separated from the C source files.
    That provides more flexibility in the use of ACSL in the life cycle of
    software since the merge between the specifications and the source code is
    done by the plug-in.
    In addition, the plug-in allows to enter ACSL annotations directly via the Graphical User
    Interface.
    Therefore `ACSL Importer` plug-in is useful only to people that intend to write
    ACSL specifications and do not want to write them inside comments of the C source files.
    ## Usage
    The use of the plug-in could be the following, except if the given options lead
    to run analysis (analysis should be launched through the graphical interface):
    - `frama-c-gui <importing options> <C files>`
    Otherwise, options have to be splitted into two groups and given as follow:
    - `frama-c-gui <importing options> <C files> -then <analysis options>`
    Once the plugin installed, the next command gives the up-to-date list of the
    plug-in options:
    - `frama-c -acsl-importer-help`
    All options of the plug-in are prefixed by `-acsl-`.
    The main options are:
    - `-acsl-importer-help`:
    lists all options specific to the plug-in
    - `-acsl-import <filename list>`:
    analyzes the content of files listed in its arguments and inserts the correctly typed
    specifications in the abstract syntax tree of Frama-C for further processing.
    - `-acsl-Idir <dirname list>`:
    specifies the list of directories where the relative file names mentioned in include
    directives are searched.
    - `-acsl-keep-unsed-symbols`:
    configures Frama-C kernel such that unused C symbols aren't removed before the import.
    - `-acsl-parse-only`:
    parses the ACSL files without typing nor imports.
    - `-acsl-typing-only`:
    parses and types the ACSL files without imports.
    - `-acsl-version`:
    pretty prints a text containing the version ID of the plugin.
    ## Example
    The plug-in can be used as follows. From a C file:
    ```c
    int f ( int i );
    int g ( int j );
    void job ( int *t , int A) {
    for ( int i = 0; i < 50; i ++) t[i] = f (i );
    for ( int j = A; j < 100; j ++) t[j ] = g(j );
    }
    ```
    and a specification file:
    ```
    function f:
    contract:
    ensures P(phi(C(\result)));
    assigns \nothing ;
    function g:
    contract: assigns \nothing ;
    function job:
    at 1: assert 50 <= A <= 100;
    at loop 1:
    loop invariant 0 <= i <= 50;
    loop invariant \forall integer k; 0 <= k < i == > P(t[k]);
    loop assigns i,t[0..49];
    at loop body 1:
    contract:
    ensures i == \old(i);
    at loop stmt 1:
    contract:
    requires i==0;
    ensures i==50;
    at loop 2:
    loop invariant A <= j <= 100;
    loop assigns j,t[A ..99];
    at return:
    assert \forall integer k; 0 <= k < 50 == > P(t[k]);
    at call f:
    contract:
    ensures P(phi(C(t[i])));
    ```
    The following command line:
    ```
    frama-c -acsl-import demo.acsl demo.c -print -no-unicode
    ```
    generates the following output:
    ```
    # frama-c -acsl-import demo.acsl demo.c -print -no-unicode
    [kernel] Parsing demo.c (with preprocessing)
    [acsl-importer] Success for demo.acsl
    [acsl-importer] Done: 1 file.
    [kernel] Parsing demo.c (with preprocessing)
    [acsl-importer] Success for demo.acsl
    [acsl-importer] Done: 1 file.
    /* Generated by Frama-C */
    /*@
    axiomatic A {
    type event = B | C(integer);
    predicate P(integer x) ;
    logic integer phi(event e) ;
    }
    */
    /*@ ensures P(phi(C(\result)));
    assigns \nothing; */
    int f(int i);
    /*@ assigns \nothing; */
    int g(int j);
    void job(int *t, int A) {
    /*@ assert 50 <= A <= 100; */
    {
    int i = 0;
    /*@ requires i == 0;
    ensures i == 50; */
    /*@ loop invariant 0 <= i <= 50;
    loop invariant \forall integer k; 0 <= k < i ==> P(*(t + k));
    loop assigns i, *(t + (0 .. 49));
    */
    while (i < 50) {
    /*@ ensures i == \old(i); */
    {
    /*@ ensures P(phi(C(*(t + i)))); */
    *(t + i) = f(i);
    }
    i ++;
    }
    }
    {
    int j = A;
    /*@ loop invariant A <= j <= 100;
    loop assigns j, *(t + (A .. 99)); */
    while (j < 100) {
    {
    *(t + j) = g(j);
    }
    j ++;
    }
    }
    /*@ assert \forall integer k; 0 <= k < 50 ==> P(*(t + k)); */
    return;
    }
    int T[100];
    void main(void) {
    job(T,50);
    return;
    }
    ```
    ## Contact
    The plug-in is currently available under a proprietary licence.
    For any questions, remarks or suggestions, please contact
    [Patrick Baudin](mailto:patrick.baudin@cea.fr?subject=[ACSL Importer]).
    _fc-plugins/aorai.md deleted 100644 → 0
    + 0
    − 95
    View file @ 895c2501
    ---
    layout: plugin
    title: Aoraï
    description: Verify specifications expressed as LTL (Linear Temporal Logic) formulas.
    key: specifications
    distrib_mode: main
    manual_pdf: /download/frama-c-aorai-manual.pdf
    ---
    ## Overview
    The **Aoraï** plug-in provides a method to automatically annotate a C program
    according to an LTL formula *F* such that, if the annotations are verified,
    then we ensure that the program respects *F*.
    The classical method to validate annotations is to use the [Wp](wp.html) or
    [Eva](eva.html) plug-ins.
    ## Installation Dependencies
    Aoraï is available in the main Frama-C distribution. It used to be
    available from http://amazones.gforge.inria.fr/aorai, but the version
    currently hosted there is obsolete and won't compile with newer versions of
    Frama-C.
    If you want to use LTL syntax for properties, you have to install the
    [ltl2ba](http://www.lsv.ens-cachan.fr/~gastin/ltl2ba/index.php) tool in your
    path. This tool is distributed by its author, Paul Gastin (ENS Cachan),
    under the GPL licence and converts an LTL formula into a Büchi automaton.
    ## Usage
    The plug-in is activated with one of the following command lines:
    frama-c file.c -aorai-ltl file.ltl
    frama-c file.c -aorai-automata file.ya
    These two commands differ only by the syntax used to express the
    property to be verified: *.ltl* files are described in an ltl-like syntax,
    while *.ya* are description of automata in an yacc-like syntax.
    Options are:
    - `-aorai-verbose`:
    Gives some information during computation, such as used/produced files
    and heuristics applied.
    - `-aorai-show-op-spec`:
    Displays, at the end of the process, the computed specification
    of each operation, in terms of Büchi states and transitions.
    - `-aorai-dot`:
    Generates a dot file of the Büchi automaton. Dot is a graph
    format used by the [GraphViz](http://www.graphviz.org) tool.
    - `-aorai-acceptance`:
    If set, considers acceptation states (Only on finite traces).
    If not, only the safety is verified.
    - `-aorai-output-c-file`: *file*
    Outputs the annotated program in *file* (the default is to
    derive a name from the one of the first input file).
    - `-aorai-help`:
    Gives the whole list of options.
    ## Installation Dependencies
    - Only the safety part of properties is checked. The liveness part is not truly
    considered. Currently, a liveness property is only a restriction that the
    terminating state of the program has to be an accepting state.
    Hence, if the program terminates, then the liveness property is verified.
    - Currently, function pointers are not supported.
    - In the init state from the automaton, conditions on C arrays and C structures
    are not statically evaluated (which would be an optimization)
    but are supported.
    ## Contact
    Aoraï has been originally written by
    [Nicolas Stouls](mailto:nicolas.stouls@insa-lyon.fr?subject=[Plug-in Aorai]),
    [CITI Labs](http://www.citi-lab.fr), [AMAZONES team](http://amazones.gforge.inria.fr).
    It is currently maintained by CEA LIST as part of the main Frama-C distribution.
    See our [contact](contact.html) page for more information.
    **End Note:** to the question "*Why this name: Aoraï?*" my answer is: why not?
    Aoraï is the name of the tallest reachable mount in the Tahiti island and its
    reachability is not always obvious.
    ## Further Reading
    - [Short documentation]({{page.manual_pdf}})
    - [A few simple examples](/download/frama-c-aorai-example.tgz)
    Other resources can be found at
    [the official web page of Aoraï](http://amazones.gforge.inria.fr/aorai/).
    _fc-plugins/cafe.md deleted 100644 → 0
    + 0
    − 31
    View file @ 895c2501
    ---
    layout: plugin
    title: CaFE
    description: Verification of CaRet temporal logic properties
    key: specifications
    distrib_mode: free
    repo_url: https://github.com/Stevendeo/CaFE
    ---
    ## Overview
    CaFE (CaRet Frama-C Extension) is a small model-checker dedicated
    to prove CaRet properties over C programs.
    [CaRet](https://doi.org/10.1007/978-3-540-24730-2_35) is
    "a temporal logic of nested calls and returns", i.e. a flavor of
    temporal logic well suited to describe a program's call stack.
    ## Usage
    [CaFE]({{page.repo_url}}) is available as a
    separate open-source plug-in. Once installed, it will be activated by
    the `-cafe` option, while `-cafe-formula` allows specifying
    the file in which to formula to be verified lies. A typical command will
    thus be the following:
    frama-c -cafe file.c -cafe-formula file.caret
    ## Dependencies
    CaFE uses [Eva](eva.html) internally to compute an over-approximation
    of the states of the program.
    _fc-plugins/conc2seq.md deleted 100644 → 0
    + 0
    − 28
    View file @ 895c2501
    ---
    layout: plugin
    title: Conc2seq
    description: Verification of concurrent programs
    key: concurrent
    distrib_mode: free
    repo_url: https://github.com/AllanBlanchard/Frama-C-Conc2Seq
    ---
    ## Overview
    Conc2seq is dedicated to the verification of concurrent C programs.
    More specifically, it proposes an instrumentation of the original code
    that simulates all possible interleavings allowed by the C standard.
    The resulting instrumented code is then a sequential program that can be
    analyzed as such. Note however that the transformation assumes that the
    original code is sequentially consistent, which must be verified independently
    (e.g. by using the [Mthread plugin](mthread.html)).
    ## Usage
    Conc2Seq is available as an external open-source [plug-in]({{page.repo_url}}).
    Once installed, it is enabled with the `-c2s` option, which will generate a
    sequential version of the concurrent API implementation provided to Frama-C.
    The generated code and specification is available a new project.
    To output this simulating program into a file, use the option
    `-c2s-output filename`.
    _fc-plugins/counter-examples.md deleted 100644 → 0
    + 0
    − 66
    View file @ 895c2501
    ---
    layout: plugin
    title: Counter-Examples
    description: Counter-example generation from failed proof attempts
    key: specifications
    distrib_mode: proprietary
    ---
    ## Overview
    The **Counter-Examples** plug-in aims at providing counter-examples from failed
    proof attempts by the [WP](wp.html) plug-in.
    More precisely, it generates a test case for the C function under analysis from
    the model given by the automated theorem prover
    (currently, only Alt-Ergo is supported).
    ## Usage
    Here are a few usage examples of the **Counter-Examples** plug-in:
    ```
    frama-c -wp [WP options] -then -ce-unknown
    ```
    This will generate counter-examples for any annotations marked with *Unknown*
    status by WP.
    ```
    frama-c -eva [Eva options] -then -ce-alarms
    ```
    This will try to generate a counter-example for each alarm generated by Eva.
    Note, however, that in the absence of additional annotations, such as function
    contracts and loop invariants, the context in which the counter-example is
    searched for will be too broad, and the generated counter-examples might be
    irrelevant.
    Other options are listed in the `README.md` and via the command-line option
    `-ce-help`.
    Counter-Examples also includes some GUI features, such as popup menu entries
    and a panel listing all generated counter-examples, with highlighting features.
    ## Technical Notes
    - Since the logical theories in which WP's proof obligations are expressed are
    undecidable, the logical model might be only partial. Namely, provers aim at
    being correct (when they answer that the property is true, this is always the
    case), and the price to pay is incompleteness (when they give a model that
    might falsify the property, the model might be spurious).
    - The Counter-Examples plug-in itself is not always able to take into account
    all the information provided by the prover, which make the counter-example
    generated at the C level less conmplete.
    ## Dependencies
    Counter-Examples depends mainly on results of the [WP](wp.html) plug-in.
    A few options depend on [Eva](eva.html).
    ## Contact
    The plug-in is currently available under a proprietary licence.
    For any questions, remarks or suggestions, please contact
    [Virgile Prevosto](mailto:virgile.prevosto@cea.fr?subject=[Counter-Examples]).
    _fc-plugins/e-acsl.md deleted 100644 → 0
    + 0
    − 78
    View file @ 895c2501
    ---
    layout: plugin
    title: E-ACSL
    description: Runtime Verification Tool.
    key: main
    priority: 1
    manual_pdf: /download/e-acsl/e-acsl-manual.pdf
    additional:
    - name: "E-ACSL language reference manual"
    short: "Language reference"
    link: /download/e-acsl/e-acsl.pdf
    - name: "E-ACSL language reference implementation manual"
    short: "Language implementation"
    name_for_main_dl: "E-ACSL implementation"
    link: /download/e-acsl/e-acsl-implementation.pdf
    distrib_mode: main
    ---
    ## Overview
    Frama-C's **E-ACSL** plug-in automatically translates an annotated C program
    into another program that detects the violated annotations at runtime.
    If no annotation is violated, the behavior of the new program is the same as
    the one of the original program.
    Combined with other Frama-C plug-ins that generate annotations, the
    verification process is pretty automatic and may verify much more properties
    than standard testing. This way, it is a
    [memory debugger](https://en.wikipedia.org/wiki/Memory_debugger)
    offering functionalities comparable to Valgrind and AddressSanitizer,
    and even more powerful.
    More precisely, possible usages include:
    - detection of a large class of undefined behaviors (in conjunction
    with the [RTE](rte.html) plug-in);
    - verification of high-level properties (in conjunction for
    instance with the [Aoraï](aorai.html) or [SecureFlow](secureflow.html)
    plug-ins);
    - complementing static and dynamic analyses (i.e. trying to
    find test cases that trigger alarms generated by [Eva](eva.html) or act
    as counter-examples for annotations marked as unknown by [WP](wp.html)),
    in conjunction with the [StaDy](stady.html) plug-in;
    - debugging specifications, in conjunction with a test-case generator such as
    [PathCrawler](pathcrawler.html) or [AFL](http://lcamtuf.coredump.cx/afl)
    ## Quick Start
    E-ACSL comes with a convenient script *e-acsl-gcc.sh* which may be called
    as follows:
    e-acsl-gcc.sh -c <files>
    It generates three files, `./a.out`, `./a.out.frama-c` and `./a.out.e-acsl`.
    The first one is the binary produced by `gcc` from the input files;
    the second one is the instrumented file with the monitor generated by E-ACSL
    from the input files. The third one is the binary produced by `gcc` from this
    latter file, so monitoring the annotations.
    Its execution behaves in the same way as the two other files, except that it
    fails if an annotation is violated.
    In order to automatically check that no **undefined behaviors** of many kinds
    are executed, the script can be simply used as follows:
    e-acsl-gcc.sh -c --rte=all <files>
    ## Dependencies
    The **E-ACSL** plug-in can use the results of both [RTE](rte.html) and
    [Eva](eva.html) plug-ins. It can be combined with several other plug-ins,
    such as [WP](wp.html), [Aoraï](aorai.html), [SecureFlow](secureflow.html),
    [StaDy](stady.html), [PathCrawler](pathcrawler.html), [MetACSL](metacsl.html), etc.
    ## Further Reading
    - [E-ACSL user manual]({{page.manual_pdf}})
    {% for add in page.additional %}
    - [{{add.name}}]({{add.link}}){% endfor %}
    _fc-plugins/eva.md deleted 100644 → 0
    + 0
    − 88
    View file @ 895c2501
    ---
    layout: plugin
    title: Eva, an Evolved Value Analysis
    short: Eva
    description: Automatically computes variation domains for the variables of the program.
    key: main
    distrib_mode: main
    priority: 0
    manual_pdf: /download/frama-c-eva-manual.pdf
    ---
    ## Value analysis based on abstract interpretation
    The **Evolved Value Analysis** plug-in computes variation domains for variables.
    It is quite automatic, although the user may guide the analysis in places.
    It handles a wide spectrum of C constructs.
    This plug-in uses abstract interpretation techniques.
    <img src="/assets/img/plugins/eva-img.png">
    The results of **Eva** can be exploited directly in two ways:
    - They can be used to infer the absence of run-time errors.
    The results are displayed in reverse, that is, alarms are emitted for all
    the operations that could lead to a run-time error. If an alarm is not
    emitted for an operation in the source code, then this operation is
    guaranteed not to cause a run-time error.
    - The Frama-C graphical user interface displays the inferred sets of possible
    values for each variable, in each point of the analyzed program.
    ## Quick Start
    The plug-in can be used both with the graphical user interface and in batch
    mode (recommended). In batch mode, the command line may look like:
    frama-c -eva file1.c file2.c
    A list of alarms (corresponding to possible run-time errors as computed by the
    analysis) is produced on the standard output.
    The results of **Eva** are used by many other plug-ins. In this case,
    the analysis is initiated automatically by the exploiting plug-in, but it is
    still possible to configure it for the case at hand (e.g. through the same
    command-line options that would be used in conjunction with `‑eva`.
    ## First Example
    Consider the following function, in file `test.c`:
    ```c
    int abs(int x) {
    if (x < 0) return -x;
    else return x;
    }
    ```
    In this code, Eva reports the possible integer overflow when `x` is the
    smallest negative integer by emitting an alarm at line 2.
    The alarm is the [ACSL](/html/acsl.html) assertion `assert -x ≤ 2147483647;`
    that protects against an overflow.
    **Eva** also displays the possible values of the variables at the end of the
    function. Here, we can see that the result is always positive.
    ```
    $ frama-c -eva test.c -main abs
    […]
    mytests/test.c:2:[eva] warning: signed overflow. assert -x ≤ 2147483647;
    [eva] done for function abs
    [eva] ====== VALUES COMPUTED ======
    [eva:final-states] Values at end of function abs:
    __retres ∈ [0..2147483647]
    ```
    One can also inspect in the graphical interface of Frama-C the alarms emitted
    by Eva, as well as the possible values inferred at each program point.
    ## Technical Notes
    - Maturity: industrialized.
    - Recursive calls are currently not supported.
    - Only sequential code can be analyzed at this time.
    ## Further Reading
    The options to configure the analysis as well as the syntax of the results are
    described in the [Eva user manual]({{page.manual_pdf}}).
    _fc-plugins/farith.md 0 → 100644
    + 15
    − 0
    View file @ e5154847
    ---
    layout: plugin
    title: Farith, proved library for FloatingPoint computation
    short: Farith
    description:
    key: main
    distrib_mode: main
    priority: 0
    manual_pdf: /download/farith-manual.pdf
    manual_html: /html/doc/farith/coq/index.html
    ---
    ## Farith
    [Coq documentation]({{page.manual_html}}).
    _fc-plugins/frama-clang.md deleted 100644 → 0
    + 0
    − 180
    View file @ 895c2501
    ---
    layout: plugin
    title: Frama-Clang
    description: C++ front-end to Frama-C, based on the clang compiler.
    key: front
    distrib_mode: free
    manual_pdf: /download/frama-clang-manual.pdf
    ---
    ![Frama-Clang logo](/assets/img/plugins/frama-clang.png)
    ## Overview
    Frama-Clang is a plugin that allows Frama-C to take as input C++ programs.
    As its name implies, it is based on the [clang](http://clang.llvm.org)
    compiler, the C/C++/Objective-C front-end of the [llvm](http://llvm.org)
    platform. More precisely, Frama-Clang is composed of two parts: a clang plugin
    (written in C++) that produces a simplified version of the clang AST, and a
    normal Frama-C plugin that takes as input this simplified version and produces
    a normal Frama-C AST.
    When this plug-in is in use, Frama-C will consider all files ending in `.cpp`,
    `.c++`, `.C`, `.cxx`, `.cc` and `.ii` (considered as already pre-processed)
    as C++ files and give them to Frama-Clang to translate them into Frama-C's
    internal representation (i.e. a plain C AST).
    Once this has been done, any existing analyses can be launched as usual.
    **Caveat:** Frama-Clang is currently in an early stage of development.
    It is known to be incomplete and comes without any bug-freeness guarantees.
    Moreover, the translation from C++ to C does not make any attempts to optimize
    the resulting code for the back-end analyzers such as [Eva](eva.html) or
    [WP](wp.html).
    Further work is thus needed before Frama-Clang can claim to be a grown-up
    plug-in. Feel free to [contact us](mailto:support@frama-c.com) if you're
    interested in participating in its maturation.
    ## Further Reading
    For more details about **Frama-Clang** plug-in,
    please consult the [Frama-Clang manual]({{page.manual_pdf}}).
    ## Installation
    ### Download
    The current version is 0.0.11. The frama-clang plugin can be downloaded
    [here](/download/frama-clang-0.0.11.tar.gz).
    Frama-Clang also has its own public git [repository](https://git.frama-c.com/pub/frama-clang),
    whose `master` branch should always be synchronized with Frama-C's own `master` branch.
    ### Requirements
    - Frama-C 23.x Vanadium
    - OCaml 4.08.0 or higher, the same version as the one used to
    compile Frama-C itself
    - camlp5 (a version compatible with the OCaml version you're using)
    - clang and libclang >= 6 (preferably >=9)
    You also need llvm-config (llvm-config-x.y for Debian and Ubuntu users,
    as explained in
    [this bug report](https://bugs.launchpad.net/ubuntu/+source/llvm-3.1/+bug/991493)).
    ### Installation steps
    ```
    tar xzvf frama-clang-0.0.11.tar.gz
    cd frama-clang-0.0.11
    ./configure
    make
    make install
    ```
    Depending on your Frama-C installation, this last step might
    require root permissions.
    ### Changes
    #### v0.0.11
    - Compatibility with Frama-C 23.x Vanadium
    - Compatibility with Clang 12.0
    - Slightly improved ACSL++ parsing
    - Various bug fixes
    #### v0.0.10
    - Compatibility with Frama-C 22.x Titanium
    - Compatibility with Clang 11.0
    - Don't generate code for implicit member functions and operators when they're
    not used.
    - Don't generate code for templated member functions that are in fact never
    instantiated.
    - header `<cstdbool>` undefines `bool`, `true` and `false` if they are macros
    (partial fix for https://git.frama-c.com/pub/frama-c/#2546)
    #### v0.0.9
    - Compatibility with Frama-C 21.x Scandium
    - Compatibility with Clang 10.0
    - Support for implicit initialization of POD objects.
    #### v0.0.8
    - Compatibility with Frama-C 20.0 Calcium
    - Compatibility with Clang 9.0
    - Proper conversion of ghost statements
    - Support for <tt>\exit_status</tt> in ACSL++
    - C++ part of the plug-in is now free from g++ warnings
    - move away from camlp4 in favor of camlp5
    #### v0.0.7
    - Compatibility with Frama-C 19.x Potassium
    - Compatibility with Clang 6.0, 7.0 and 8.0
    - Rewritten ACSL++ parser, providing easier extensibility
    and maintenance
    - Frama-Clang now has a
    [manual]({{page.manual_pdf}})
    - Improved support of STL
    - Preliminary support for lambdas
    - Improved support of template instantiations
    #### v0.0.6
    - Compatibility with Frama-C 17 Chlorine
    #### v0.0.5
    - Compatibility with Clang/LLVM as packaged by Debian/Ubuntu
    #### v0.0.4
    - Compatibility with Frama-C 16 Sulfur
    - Compatibility with Clang/LLVM 5.0.0
    - Improved translation for `const`-qualified objects
    - Fixes translation of implicit functions for classes with
    virtual inheritance
    #### v0.0.3
    - Compatibility with Frama-C 15 Phosphorus
    - Improved handling of constructors and destructors for local
    variables
    #### v0.0.2
    - Compatibility with Frama-C 14 Silicon
    - Adding compatibility with Clang/LLVM 3.9.0 and 4.0.0
    - Various fixes in support of virtual inheritance and
    templates
    - Better support for parsing GNU STL headers
    #### v0.0.1
    - Initial release
    ### Previous versions
    - [0.0.10](/download/frama-clang-0.0.10.tar.gz)
    compatible with Frama-C 22.0
    - [0.0.9](/download/frama-clang-0.0.9.tar.gz)
    compatible with Frama-C 21.0
    - [0.0.8](/download/frama-clang-0.0.8.tar.gz)
    compatible with Frama-C 20.0
    - [0.0.7](/download/frama-clang-0.0.7.tar.gz)
    compatible with Frama-C 19.x
    - [0.0.6](/download/frama-clang-0.0.6.tar.gz)
    compatible with Frama-C 17.0
    - [0.0.5](/download/frama-clang-0.0.5.tar.gz)
    compatible with Frama-C Sulfur-20171101
    - [0.0.5](/download/frama-clang-0.0.4.tar.gz)
    compatible with Frama-C Sulfur-20171101
    - [0.0.3](/download/frama-clang-0.0.3.tar.gz)
    compatible with Frama-C Phosphorus-20170501
    - [0.0.2](/download/frama-clang-0.0.2.tar.gz)
    compatible with Frama-C Silicon-20161101
    - [0.0.1](/download/frama-clang-0.0.1.tar.gz)
    compatible with Frama-C Aluminium-20160502
    <p style="font-size: .8em"><a name="credit" id="credit"></a> The
    llvm wyvern logo is <a href="http://llvm.org/Logo.html">© Apple,
    inc</a>
    _fc-plugins/impact.md deleted 100644 → 0
    + 0
    − 40
    View file @ 895c2501
    ---
    layout: plugin
    title: Impact analysis
    short: Impact
    description: Highlights the locations in the source code that are impacted by a modification.
    key: browsing
    distrib_mode: main
    ---
    ## Overview
    The **Impact analysis** plug-in allows the automatic computation of the set of
    statements impacted by the side effects of a statement of a C program.
    Statements not appearing in this set are guaranteed not to be impacted by the
    selected statement.
    Impact analysis is available through a contextual menu at each statement in the
    Frama-C graphical user interface. Invoking this analysis on a statement
    displays the impact of the statement on the rest of the program.
    ![Impact screenshot on the GUI](/assets/img/plugins/impact-img.png)
    ## Usage
    The plug-in can be used both with the graphical user interface and in batch
    mode. In batch mode, you must put pragmas on the statements you want to analyze:
    `/*@ impact pragma stmt; */`
    Then, the following command line computes the impact from the pragma statements
    in the code of functions `f1,...,fn`:
    frama-c -impact-pragma f1,...,fn file1.c file2.c
    To print the list of impacted statements on the standard output:
    frama-c -impact-print file1.c file2.c
    ## Dependencies
    This plug-in depends on results of the [Eva](eva.html) plug-in.
    _fc-plugins/instantiate.md deleted 100644 → 0
    + 0
    − 88
    View file @ 895c2501
    ---
    layout: plugin
    title: Instantiate
    description: Creates function specializations for other plugins.
    key: code
    distrib_mode: main
    ---
    ## Overview
    The **Instantiate** plug-in is meant to build function specializations for
    C functions when the original specification (or prototype of the function)
    cannot be efficiently used by some plugins. Generally, it is used to
    specialize functions that receive `void*` parameters.
    For each compatible call, **Instantiate** replaces it with a call to an
    automatically generated specialization. Note that the contract of the
    generated function is considered verified.
    ## Quick Start
    The plug-in is enabled by setting the option `-instantiate`. The result
    can be output via the kernel option `-print`. It can also be directly
    used by other plug-ins.
    ## Example
    Example input:
    ```
    #include <string.h>
    void main(void){
    char copy[13];
    memcpy(copy, "Hello world!", 13);
    }
    ```
    Example output:
    ```
    /* Generated by Frama-C */
    #include "stddef.h"
    #include "string.h"
    #include "strings.h"
    /*@ requires
    separation: \separated(dest + (0 .. len - 1), src + (0 .. len - 1));
    requires aligned_end: len % 1 ≡ 0;
    requires valid_dest: \valid(dest + (0 .. len - 1));
    requires valid_read_src: \valid_read(src + (0 .. len - 1));
    ensures
    copied: ∀ ℤ j0; 0 ≤ j0 < len ⇒ *(dest + j0) ≡ *(src + j0);
    ensures result: \result ≡ dest;
    assigns *(dest + (0 .. len - 1)), \result;
    assigns *(dest + (0 .. len - 1)) \from *(src + (0 .. len - 1));
    assigns \result \from dest;
    */
    char *memcpy_char(char *dest, char const *src, size_t len)
    {
    char *__retres;
    __retres = (char *)memcpy((void *)dest,(void const *)src,len);
    return __retres;
    }
    void main(void)
    {
    char copy[13];
    memcpy_char(copy,"Hello world!",(unsigned int)13);
    return;
    }
    ```
    ## Technical Notes
    - The default behavior of this plugin is to replace calls in every
    function. The option `-instantiate-fct` can be used to select the
    functions to process.
    - Currently, the plugin supports `memcmp`, `memcpy`, `memmove`,
    `memset` (partially, check the `README` for more details),
    `malloc`, `calloc` and `free`. The support of each of this function
    is enabled by default and can be deactivated using the option
    `-instantiate-no-<function name>`.
    ## Further Reading
    Information about the plug-in is available via its help option:
    frama-c -instantiate-help
    _fc-plugins/jcard.md deleted 100644 → 0
    + 0
    − 24
    View file @ 895c2501
    ---
    layout: plugin
    title: JCard
    description: JavaCard Front-End for Frama-C
    key: front
    distrib_mode: obsolete
    ---
    ## Overview
    JCard is a JavaCard front-end for Frama-C, based on
    [JavaLib and Sawja](http://javalib.gforge.inria.fr/).
    It is meant to transform Java bytecode into Frama-C's internal C
    representation. After that, main analysis plug-ins can operate as
    usual.
    ## Usage
    Once installed, JCard will automatically consider any `.java`
    or `.class` file passed on the Frama-C command line as java input
    and attempt to parse them.
    JCard is not publicly released, and there is no guarantee that it
    is compatible with the current Frama-C version. It is usually made available
    as part of collaborative projects or through direct partnerships.
    _fc-plugins/jessie.md deleted 100644 → 0
    + 0
    − 35
    View file @ 895c2501
    ---
    layout: plugin
    title: Jessie
    description: A deductive verification plug-in.
    key: main
    distrib_mode: obsolete
    ---
    ## Overview
    **Warning** Jessie is currently not actively maintained and
    probably incompatible with the latest Frama-C versions.
    The **Jessie** plug-in allows deductive verification of C programs annotated
    with [ACSL](acsl.html). It uses internally the languages and tools of the
    [Why3](http://why3.lri.fr) environment.
    The generated verification conditions can be submitted to many external
    automatic provers including
    [Alt-Ergo](https://alt-ergo.ocamlpro.com/),
    [Z3](https://github.com/Z3Prover) and [CVC4](https://cvc4.github.io/).
    For more complex situations, interactive theorem provers can be used to
    establish validity of VCs. Please look at the
    [Jessie](http://krakatoa.lri.fr) web page for more details.
    ## Usage
    The plug-in is activated with the following command line:
    frama-c -jessie [options] <file>.c
    A short manual including a tutorial and reference is available on the
    [Jessie](http://krakatoa.lri.fr) web page. Please read this document for
    details on other command-line options, as well as supported and unsupported
    features.
    _fc-plugins/markdown-report.md deleted 100644 → 0
    + 0
    − 42
    View file @ 895c2501
    ---
    layout: plugin
    title: Markdown Report (MdR)
    short: MdR
    description: Markdown and SARIF reports on status of ACSL annotations
    key: reporting
    distrib_mode: main
    ---
    ## Overview
    Markdown Report, or MdR for short,
    is meant to provide a summary of the status (valid, invalid,
    unknown) of ACSL annotations present in the code under analysis. It
    features a draft mode, which will output a skeleton of a report in the
    [pandoc-markdown](https://pandoc.org/MANUAL.html#pandocs-markdown)
    format, with some space left for the user to provide additional
    information about the context of the analysis, such as an explanation
    about the ACSL specification used for stubbing a function,
    or the reasons why an alarm emitted by[Eva](eva.html)
    is in fact a false alarm and can thus be ignored.
    Once the user is satisfied with the text they have provided, the final
    document can be produced by MdR. Two output formats can be chosen, either
    Pandoc Markdown, which can then be transformed into more popular
    formats (pdf, docx, odt, html, ...) with the
    [pandoc](https://pandoc.org) tool; or
    [SARIF](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif),
    the *Static Analyzer Results Interchange Format*,
    a JSON schema aiming at unifying the output formats of static analyzers.
    ## Usage
    MdR is part of the main distribution of Frama-C. It is typically
    used after a main analysis, e.g. with:
    frama-c -eva file.c -then -mdr-gen sarif -mdr-out file.json
    ## Technical Notes
    MdR is currently in an early stage of development; notably, its SARIF
    output is known to be incomplete.
    _fc-plugins/metacsl.md deleted 100644 → 0
    + 0
    − 52
    View file @ 895c2501
    ---
    layout: plugin
    title: MetAcsl
    description: Verification of high-level ACSL requirements
    key: specifications
    distrib_mode: free
    repo_url: https://git.frama-c.com/pub/meta
    ---
    ## Overview
    MetAcsl is a plug-in dedicated to specifying and verifying
    *high-level ACSL requirements* (HILARE), that is, properties that are supposed
    to be checked at many points of the code base under analysis,
    so that writing the corresponding ACSL annotations manually
    would be extremely tedious and error-prone. A simple example
    of such a requirement would be a confidentiality property indicating
    that no access to a particular memory block should occur unless
    some clearance condition holds. Specifying that in pure ACSL
    would require writing an assertion for each read access in the
    code, while MetAcsl only needs a single HILARE.
    In summary, MetAcsl defines a global ACSL extension for describing
    HILAREs, that are composed of three elements:
    - a target: the set of functions where the HILARE should hold;
    - a context: the kind of program points that are concerned by the
    HILARE. Two important contexts are `\writing` and
    `\reading` accesses;
    - the property itself: it is an ACSL predicate, possibly enriched
    with meta-variables, depending on the context. For instance,
    a `\writing` context gives rise to a `\written`
    meta-variable denoting the location being written to.
    The plug-in proceeds by generating all ACSL annotations corresponding to
    each HILARE. It is then possible to use one of the main analysis
    plug-ins of the platform (e.g. [WP](wp.html),
    [E-ACSL](e-acsl.html), or [Eva](eva.html)) to
    verify these annotations.
    ## Usage
    MetAcsl is available as a separate open-source plug-in, on [Gitlab](https://git.frama-c.com/pub/meta) (more information there).
    It is intended to be compatible with the latest state of [Frama-C's public repository](https://git.frama-c.com/pub/frama-c).
    For installing the plug-in against the stable version Frama-C 22.0 Titanium,
    there also exists a companion [MetAcsl 0.1 release](https://git.frama-c.com/pub/meta/-/releases/0.1). It is also available through `opam` as the
    `frama-c-metacsl` package.
    Once installed, the plugin is activated by the `-meta` option, which will parse the meta-properties and generate the corresponding ACSL annotations.
    _fc-plugins/metrics-calculation.md deleted 100644 → 0
    + 0
    − 40
    View file @ 895c2501
    ---
    layout: plugin
    title: Metrics calculation
    short: Metrics
    description: Allows the user to compute various metrics from the source code.
    key: reporting
    distrib_mode: main
    manual_pdf: /download/frama-c-metrics-manual.pdf
    ---
    ## Overview
    The **Metrics** plug-in allows the automatic computation of various measures
    on the source code.
    It can be used to compute the following measures:
    - McCabe's cyclomatic complexity;
    - Halstead complexity;
    - Eva coverage estimate.
    ## Usage
    This plug-in can be partly used with the graphical user interface.
    In batch mode, the command line may look like:
    frama-c -metrics file1.c file2.c
    ## Dependencies
    This plug-in depends on results of the [Eva](eva.html) plug-in for the
    `-metrics-eva-cover` option.
    ## Further Reading
    The use of this plug-in is detailed in its
    [short documentation]({{page.manual_pdf}}).
    _fc-plugins/mthread.md deleted 100644 → 0
    + 0
    − 93
    View file @ 895c2501
    ---
    layout: plugin
    title: Mthread
    description: Analyzes concurrent C programs, taking into account all possible thread interactions. Provides precise information about shared variables, which mutex protects a part of the code, etc.
    key: concurrent
    distrib_mode: proprietary
    manual_pdf: /download/frama-c-mthread-manual.pdf
    ---
    ## Overview
    The **Mthread** plug-in automatically analyzes concurrent C programs,
    using the techniques used by Eva. At the end of its execution, the concurrent
    behavior of each thread is over-approximated. Thus, the information delivered
    by the plug-in takes into account all the *possible concurrent behaviors* of
    the program.
    The results of Mthread are many-fold:
    - For each thread, all possible instructions that can lead to a
    *run-time error*. As explained above, this information takes into account all
    possible *interleavings* between all threads.
    - An over-approximation of the *memory zones that are accessed concurrently*
    by more than one thread. For each zone and thread, Mthread also returns the
    program points at which the zone is accessed, whether the zone is read or
    written, and the callstack that leads to the statement.
    - At each program point, the list of mutexes that can be locked by the current
    thread. This information is used to identify shared memory zones on which
    *race conditions* may occur.
    - An over-approximation of the messages exchanged by all threads through
    *explicit message-passing*, along with the emission and reception points.
    - For each thread, a slicing of all the statements it can execute, in which only
    the statements related to concurrency are kept. See for example
    [this graph](/download/frama-c-mthread-graph.svg).
    - For each program point of each thread, an over-approximation of the possible
    values.
    ## Usage
    The plug-in is activated with the following command line:
    ```
    frama-c -mthread file1.c file2.c ... concurrent_library.c
    ```
    Notice that you must explicitly pass a stubbed version of your concurrency
    library on the command-line. Support for the often used `pthread` primitives
    is included in the plug-in. Preliminary support for the `VxWorks` and `Win32`
    libraries also exist.
    The main options are:
    - `-mt-verbose`:
    Gives some additional information during computation.
    - `-mt-shared-zones *n*`:
    Shows the values written in all shared zones at level 1,
    and with the calling contexts in which they are written at level 2.
    - `-mt-print-callstacks`:
    Prints the calling context at which the concurrent operations occur.
    - `-mt-extract html`:
    Generates an HTML summary of the results, as well as the concurrent (sliced)
    graphs of each thread.
    ## Technical Notes
    - The detection of race condition supposes that shared zones are protected by
    mutexes. Lock-free algorithms are not detected as such.
    - Using the plug-in requires stubbing the concurrency library, if it is not
    amongst of the available ones (currently `pthread`, `VxWorks` and `Win32`).
    ## Dependencies
    This plug-in depends on results of the [Eva](eva.html) plug-in.
    ## Further Reading
    - [User manual]({{page.manual_pdf}})
    - [A few examples, with the outputs of the plugin](/download/frama-c-mthread-examples.tgz)
    ## Contact
    The plug-in is currently available under a proprietary licence.
    For any questions, remarks or suggestions, please contact
    [Tristan Le Gall](mailto:tristan.le-gall@cea.fr?subject=[Mthread]).
    _fc-plugins/occurrence.md deleted 100644 → 0
    + 0
    − 34
    View file @ 895c2501
    ---
    layout: plugin
    title: Occurrence analysis
    short: Occurrence
    description: Allows the user to reach the statements where a given variable is used. Also provided as a simple example for new plug-in development.
    key: browsing
    distrib_mode: main
    ---
    ## Overview
    The **Occurrence analysis** plug-in shows the uses of a variable in a C program.
    This analysis highlights the left-values that may access the selected variable.
    As shown by the example, the analysis takes aliases into account.
    It is available through a contextual menu at each variable in the Frama-C
    graphical user interface. Invoking this analysis on a variable displays
    the occurrences of this variable in the program:
    ![Screenshot of Occurrence in the GUI](/assets/img/plugins/occurrence-img.png)
    ## Usage
    The plug-in can be used both with the graphical user interface and in batch mode.
    In batch mode, the command is:
    frama-c -occurrence file1.c file2.c
    This prints all occurrences of each variable to the standard output.
    ## Dependencies
    This plug-in depends on results of the [Eva](eva.html) plug-in.
    _fc-plugins/pathcrawler.md deleted 100644 → 0
    + 0
    − 107
    View file @ 895c2501
    ---
    layout: plugin
    title: PathCrawler
    description: White-box test cases generator.
    key: main
    distrib_mode: proprietary
    manual_pdf: /download/frama-c-pathcrawler.pdf
    ---
    ## Overview
    PathCrawler automatically generates test-case inputs.
    ![Screenshot of Pathcrawler Online](/assets/img/plugins/pathcrawler-img.png)
    ## What's it for?
    **PathCrawler**'s principal functionality is to automate structural unit
    testing by generating test inputs which cover all the feasible execution
    paths of the C function under test.
    It can also be used to satisfy other coverage criteria
    (like *k-path* coverage restricting the all-path criterion to paths with
    at most *k* consecutive loop iterations, branch coverage, MC-DC, ...),
    to generate supplementary tests to improve coverage of an existing functional
    test suite or to generate just the tests necessary to cover the part of the
    code which has been impacted by a modification.
    **PathCrawler** can be used to ensure, and demonstrate, code coverage when
    this is imposed by a standard.
    However, it can also be used even when code coverage is not imposed,
    as a convenient and rigorous way of debugging code fragments during development.
    Apart from generating tests to ensure coverage, **PathCrawler** can be used to
    detect all run-time errors, anomalies such as uninitialized variables or
    integer overflows and unreachable code.
    Another use is to cross-check one implementation against another
    (previous version or implementation for another platform) or to check conformity
    with a specification coded in C. **PathCrawler** will either find test-cases to
    demonstrate any differences between the results of the two codes or else
    demonstrate that no such differences exist.
    The path tests generated by **PathCrawler** can also be used to measure the
    effective execution time of an uninterrupted task in a real-time application,
    and get an accurate estimate of the longest execution time.
    ## Can I try it?
    The [PathCrawler-online](http://PathCrawler-online.com/) web service makes a
    restricted version of **PathCrawler** freely available for evaluation and
    teaching. The user uploads the C source code to be tested and the server
    displays the test-cases generated by **PathCrawler** and a detailed
    justification of the coverage. The user can define the test context and browse
    the results using specialized interfaces in the form of web-pages. The server
    allows many test-case generation sessions to be run in parallel in a
    completely robust and secure way.
    Automatic testing tools allow huge savings but they do not exonerate the user
    from thinking carefully about what they want testing to achieve.
    To successfully use **PathCrawler**, the user must provide not only the full
    source code (with C stubs for missing functions), but also must set the test
    parameters and program the oracle. This demands a different "mindset" from that
    used for manual unit testing and so **PathCrawler-online** proposes numerous
    code examples to help the user get started and a tutorial based on some of
    these examples.
    Users who have tried **PathCrawler-online** and would like to use the
    **PathCrawler** plug-in are invited to contact
    [PathCrawler@cea.fr](mailto:PathCrawler@cea.fr) to obtain the executable code.
    This usually necessitates the signature of a non-disclosure agreement but no
    payment in the case of use for research or evaluation.
    ## Usage
    The plug-in is activated with the following command line:
    ```
    frama-c -pc [options] -main <tested function> <file>.c
    ```
    ## Technical Notes
    Note that **PathCrawler** is based on constraint resolution, which is
    NP-complete. This means that finding a test or demonstrating the infeasibility
    of the path to be covered, cannot always be guaranteed to terminate within
    a reasonable time. When this occurs, **PathCrawler** reports that the
    corresponding path is probably infeasible but that this cannot be demonstrated.
    This problem is usually only posed by functions under test which implement
    numerical algorithms in which the branch conditions involve the results of
    complex calculations.
    A different problem is posed by functions which have too many easible execution
    paths for all-path coverage to be practical, even when the effective calling
    context is taken into account. Indeed, the number of execution paths suffers
    from a combinatorial explosion in the presence of loops with input-dependent
    limits, cascades of conditional instructions, function calls, etc. For these
    functions, another coverage criterion may have to be used.
    Various specialised criteria are currently being developed.
    Finally, there are [certain constructions in C](http://pathcrawler-online.com)
    which **PathCrawler** cannot treat yet
    (Menu Documentation, Section "Limitations of PathCrawler").
    ## Further Reading
    For further details, see the [Pathcrawler user manual]({{page.manual_pdf}}).
    0% or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Finish editing this message first!
    Please register or to comment