Skip to content
Snippets Groups Projects
wp_plugin.tex 78.3 KiB
Newer Older
\chapter{Using the WP Plug-in}
\label{wp-plugin}

The \textsf{WP} plug-in can be used from the \textsf{Frama-C} command line 
or within its graphical user interface. It is a
dynamically loaded plug-in, distributed with the kernel since the
\textsf{Carbon} release of \textsf{Frama-C}.

This plug-in computes proof obligations of programs annotated with
\textsf{ACSL} annotations by \emph{weakest precondition calculus},
using a parametrized memory model to represent pointers and heap
values. The proof obligations may then be discharged by external
decision procedures, which range over automated theorem provers such
as \textsf{Alt-Ergo}~\cite{AltErgo2006}, interactive proof assistants
like \textsf{Coq}~\cite{Coq84} and the interactive proof manager
\textsf{Why3}~\cite{Why3}.

This chapter describes how to use the plug-in, from the
\textsf{Frama-C} graphical user interface (section~\ref{wp-gui}), from
the command line (section~\ref{wp-cmdline}), or from another plug-in
(section~\ref{wp-api}).  Additionally, the combination of the \textsf{WP}
plug-in with the load and save commands of \textsf{Frama-C} and/or the
\texttt{-then} command-line option is explained in section~\ref{wp-persistent}.

\clearpage
%-----------------------------------------------------------------------------
\section{Installing Provers}
\label{wp-install-provers}
%-----------------------------------------------------------------------------

The \textsf{WP} plug-in requires external provers to work.
The natively supported provers are:
\begin{center}
  \begin{tabular}{crlc}
    Prover & Version & Download &\\
    \hline
    \textsf{Alt-Ergo} & \verb|0.99.1| to \verb|2.0.0| & 
    \url{http://alt-ergo.ocamlpro.com} & \cite{AltErgo2006}\\
    \textsf{Coq} & \verb|8.5|, \verb|8.6| or \verb|8.7| & 
    \url{http://coq.inria.fr} & \cite{Coq84}\\
    \textsf{Why3} & \verb|0.88+| & 
    \url{http://why3.lri.fr} & \cite{Why3}\\
  \end{tabular}
\end{center}

Recent \textsf{OPAM}-provided versions should work smoothly.

Other provers, like \textsf{Gappa}, \textsf{Z3}, \textsf{CVC3},
\textsf{CVC4}, \textsf{PVS}, and many others, are accessible from
\textsf{WP} through \textsf{Why3}. We refer the user to the manual of
\textsf{Why3} to handle specific configuration tasks.

Provers can be installed at any time, before or after the installation
of \textsf{Frama-C/WP}. However, when using \textsf{Coq} and
\textsf{Why-3}, it is better to install them before, or to
re-configure and re-install \textsf{WP}, as explained below.

\paragraph{Configuration.} When using \textsf{Coq} and \textsf{Why-3}, pre-compiled 
libraries are built during the compilation of \textsf{Frama-C}, which
speed up the proof process in a significant way. This behavior can be
turned on/off at configure time, typically:
\begin{logs}
# configure --disable-wp-coq --disable-wp-why3
\end{logs}

\paragraph{Compilation.} If you want to compile the \textsf{Coq} and \textsf{Why-3} 
libraries manually, you can still run:
\begin{logs}
# make wp-coq wp-why3
# [sudo] make wp-coq-install
\end{logs}

\paragraph{Remark.} The \textsf{Why}~\cite{Filliatre2003} prover is no longer supported 
since \textsf{WP} version \verb+0.7+ (Fluorine).

\clearpage
%-----------------------------------------------------------------------------
\section{Graphical User Interface}
\label{wp-gui}
%-----------------------------------------------------------------------------

\newcommand{\loadicon}[1]{\raisebox{-3pt}{\rule{0pt}{13pt}\includegraphics[height=12pt]{#1}}}

To use the \textsf{WP} plug-in with the GUI, you simply need to run the
\textsf{Frama-C} graphical user interface. No additional option is
required, although you can preselect some of the \textsf{WP} options
described in section~\ref{wp-cmdline}:

\begin{shell}
  \$ frama-c-gui [options...] *.c
\end{shell}

\begin{figure}[p]
\begin{center}
\includegraphics[width=\textwidth]{wp-gui-main.png}
\end{center}
\caption{WP in the Frama-C GUI}
\label{wp-gui-panel}
\end{figure}

\begin{figure}[p]
\begin{center}
\includegraphics[width=\textwidth]{wp-gui-run.png}
\end{center}
\caption{WP run from the GUI}
\label{wp-gui-run}
\end{figure}

As we can see in figure~\ref{wp-gui-panel}, the memory model, the
decision procedure, and some \textsf{WP} options can be tuned from the
\textsf{WP} side panel. Other options of the \textsf{WP} plug-in are still
modifiable from the \texttt{Properties} button in the main GUI toolbar.

To prove a property, just select it in the internal source view and
choose \textsf{WP} from the contextual menu. The \texttt{Console}
window outputs some information about the
computation. Figure~\ref{wp-gui-run} displays an example of such a
session.

If everything succeeds, a green bullet should appear on the left of
the property. The computation can also be run for a bundle of
properties if the contextual menu is open from a function or behavior
selection.

The options from the \textsf{WP} side panel correspond to some options
of the plug-in command-line. Please refer to section~\ref{wp-cmdline}
for more details. In the graphical user interface, there are also
specific panels that display more details related to the \textsf{WP} plug-in,
that we shortly describe below.

\paragraph{Source Panel.} On the center of the \textsf{Frama-C} window, the status 
of each code annotation is reported in the left margin. The meaning of
icons is the same for all plug-ins in \textsf{Frama-C} and more precisely described
in the general user's manual of the platform. The status emitted by the \textsf{WP} plug-in are:
\begin{center}
  \begin{tabular}{cl}
    \multicolumn{2}{l}{\bf Icons for properties:} \\
    \hline
    \loadicon{feedback/never_tried.png} & No proof attempted. \\
    \loadicon{feedback/unknown.png} & The property has not been validated. \\
    \loadicon{feedback/valid_under_hyp.png} & The property is \emph{valid} but has dependencies. \\
    \loadicon{feedback/surely_valid.png} & The property and \emph{all} its dependencies are \emph{valid}. \\
    \hline
  \end{tabular}
\end{center}

\paragraph{WP Goals Panel.}
This panel is dedicated to the \textsf{WP} plug-in. It shows the
generated proof obligations and their status for each prover.
By clicking on a prover
column, you can also submit a proof obligation to a prover by
hand. Right-click provides more options depending on the prover, such
as proof-script editing for \textsf{Coq}.

\paragraph{Interactive Proof Editor.}
From the Goals Panel view, you can double-click on a row and open the \emph{interactive proof editor} panel as described in section~\ref{wp-proof-editor}.

\paragraph{Properties Panel.} This panel summarizes the consolidated 
status of properties, from various plug-ins. This panel is not
automatically refreshed. You should press the \texttt{Refresh} button
to update it. This panel is described in more details in the general
\textsf{Frama-C} platform user's manual.

\clearpage
%-----------------------------------------------------------------------------
\section{Interactive Proof Editor}
\label{wp-proof-editor}
%-----------------------------------------------------------------------------

This panel focus on one goal generated by \textsf{WP}, and allow the user to visualize the logical sequent to be proved, and to interactively decompose a complex proof into smaller pieces by applying \emph{tactics}.

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=\textwidth]{wp-tip-run.png}
\end{center}
\caption{Interactive Proof Editing}
\label{wp-tip-run}
\end{figure}

The general structure of the panel is illustrated figure~\ref{wp-tip-run}. The central text area prints the logical sequent to proved. In consists of a formula to \verb+Prove+ under the hypotheses listed in the \verb+Assume+ section. Each hypothesis can consists of :
\begin{quote}
\begin{tabular}{ll}
\verb+Type:+& formula expressing a typing constraint;\\
\verb+Init:+& formula characterizing global variable initialisation;\\
\verb+Have:+& formula from an assertion or an instruction in the code;\\
\verb+When:+& condition from a simplification performed by \textsf{Qed};\\
\verb+If:+& structured hypothesis from a conditional statement;\\
\verb+Either:+& structured disjunction from a switch statement.\\
\verb+Stmt:+& labels and C-like instructions representing the memory updates during code execution;\\
\end{tabular}
\end{quote}

\subsection{Display Modes}

There are several modes to display the current goal:
\begin{quote}
\begin{tabular}{ll}
\verb+Autofocus:+ & filter out clauses not mentioning \emph{focused} terms (see below);\\
\verb+Full Context:+ & disable autofocus mode --- all clauses are visible; \\
\verb+Unmangled Memory:+ & autofocus mode with low-level details of memory model; \\
201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918
\verb+Raw Obligation:+ & no autofocus and low-level details of memory model.
\end{tabular}
\end{quote}

\paragraph{Remark:} the fold/unfold operations only affect the goal display. It does not \emph{transform} the goal to be proven.

The autofocus mode is based on a ring of \emph{focused terms}. Clicking a term of a clause automatically focus this term. Shift-clicking a term adds the term to the focus ring. When autofocus mode is active, only the clauses that contains a \emph{focused} term are displayed. Hidden clauses are mentioned by an ellipsis \texttt{[...]}.

Low-level details of the memory model are normally hidden, and represented by C-like instructions such as:

\begin{ccode}
   Stmt { Label A: a.f[0] = y@Pre; }
\end{ccode}

This reads as follows: a program point is defined by the label \texttt{A}. At this point, the left-value \texttt{a.f[0]} receives the value that variable \texttt{y} holds at label \texttt{Pre}. More generally, \texttt{lv@L} means the value of l-value \texttt{lv} at label \texttt{L:}, and for more complex expression, \texttt{« e »@L} means the expression \texttt{e} evaluated at label \texttt{L}. Redundant labels are removed when possible. This is a short-hand for \textsf{ACSL} notation \lstinline{\at(e,L)} but is generally more readable.

Sometimes, some memory operations can not be rendered as C instructions, typically after transforming a goal so far. In such situations, the memory model encoding might appear with terms like \texttt{µ:Mint@L}.

With memory model unmangled, the encoding in logic formulae is revealed and no label are displayed.

\subsection{Tactics}

The right panel display a palette of tactics to be applied on the current goal. Tooltips are provided to help the user understanding how to configure and run tactics. 

Only applicable tactics are displayed, with respect to current term or clause selected. Many tactics can be configured by the user to tune their effect. Click on the tactic button to toggle its control panel. Once a tactic is correctly configured, it can be applied by clicking its « Play » button.

\subsection{Term Composer}

Some tactic require one or several terms to be selected.
In such case, the normal view display the selected term.
It can be edited by buttons in the view, like a \texttt{RPN} calculator. More buttons appear with respect to already selected terms. Numerical constants can be composed, and combined with selected terms.

Typically, the composer displays a stack of values, like for instance:
\begin{ccode}
  A: 45
  B: a[0]@Pre (int)
\end{ccode}

In such a case, the user can select the value \texttt{45} with the \texttt{Select A} button, or add the two numbers with the \texttt{Add A+B} button.

Sometimes, like for the Instance tactic, a \emph{range} of numerical values can be selected. In such a case, when two numbers are selected, a special button \texttt{Select A..B} appears.

The list of all available composer buttons is displayed by the \texttt{Help} button.

A composer worth to be mentioned is \texttt{Destruct}, typically available on complex expressions. It allows to decompose a value into its sub-components. For instance, destructuring the value \texttt{B} above will reveal the address \texttt{« a+0 »@Pre} and memory \texttt{µ:Mint@Pre}.

\subsection{Proof Script}

The top toolbar upon the goal display show the current status of the goal and the number of pending goals. The media buttons allow to navigate in the proof tree.
\begin{quote}
\begin{tabular}{ll}
\verb+Next/Prev:+ & navigate among the list of pending (non proved) sub-goals; \\
\verb+Forward:+ & goes to the next pending sub-goal; \\
\verb+Backward:+ & cancel the current tactic and prover results; \\
\verb+Clear:+ & restart all the interactive proof from the initial goal.
\end{tabular}
\end{quote}

A sketch of current proof is displayed on top of the goal ; each step is clickable to navigate into the proof. Only the path leading to the current node is unfolded.

When all pending sub-goals have been proved, the initial goal is marked proved by \textsf{Tactical} in the goal list panel. It is time to save the script. A button is also available to replay the saved script, if any. Saving and replay are also accessible from the list of goals, in the popup menu of the \texttt{Script} prover column.

\subsection{Replaying Scripts}

Editing scripts interactively allows the user to finish the proofs. Once proofs are saved, he must be able to replay them from the command line. To ease the process, the following options are available to the user:
\begin{quote}
\begin{tabular}{ll}
\verb+-wp-session <dir>+ & to setup a directory where scripts are saved in; \\
\verb+-wp-prover tip+ & for incrementally building and updating the session scripts;\\
\verb+-wp-prover script+ & for replaying saved scripts only, as they are;\\
\end{tabular}
\end{quote}

The \verb+script+ prover only runs the proof scripts edited by the user from the TIP, including the scripts being complete or known to being stuck at some sub-goal. The other proof obligations are transmitted to other provers, if some are provided.

This mode is well suited for replaying a proof bench, by using a combination of provers such as \verb+-wp-prover script,alt-ergo+. Moreover, the \verb+script+ prover never modifies the proof session and the proof scripts.

The \verb+tip+ prover is similar, except that it never runs sub-goals that are known to be stuck but updates the proof scripts on success or when an automated proof fails. Using the \verb+tip+ prover is less time consuming and eventually prepares new scripts for failed proofs to be edited later under the TIP.

\clearpage
A typical proof session consists then in the following stages:

a. Collecting the automated proofs and preparing for the TIP.
\begin{logs}
  frama-c [...] -wp-prover tip,alt-ergo
\end{logs}

This runs all existing scripts (none at the very beginning) in success-mode only, and try Alt-Ergo on the others. Failed proofs lead to new empty scripts created.

b. Running the TIP.
\begin{logs}
  frama-c-gui [...] -wp-prover tip
\end{logs}

This mode only runs existing scripts (typically prepared in the previous phase) in success-mode only, which is quite fast. Finally, the GUI is opened and the user can enter the TIP and edit the proofs.

Most goals are reported not to be proved, because automated proof is deactivated since no other prover than \verb+tip+ is specified. However, by filtering only those proof scripts that requires completion, only the relevant goals appear. The user has to save its edited proof scripts to re-run them later.

Any number of phase a. and b. can be executed and interleaved. This incrementally builds the set of proof scripts that are required to complement the automated proofs.

c. Consolidating the Bench.
\begin{logs}
  frama-c [...] -wp-prover script,alt-ergo    
\end{logs}

This mode replays the automated proofs and the interactive ones, re-running Alt-Ergo on every WP goals and every proof tactic sub-goals. The user scripts are never modified — this is a replay mode only.

\clearpage
\subsection{Available Tactics}

\newcommand{\TACTIC}[2]{#1\quad\quad\triangleright\quad\quad#2}

\paragraph{Absurd} Contradict a Hypothesis\\
The user can select a hypothesis $H$, and change the goal to $\neg H$:

$$ \TACTIC{\Delta,H\models\,G}{\Delta\models\,\neg H} $$


\paragraph{Array} Decompose array access-update patterns\\
The use select an expression $e\equiv a[k_1\mapsto v][k_2]$. Then:

$$ \TACTIC{\Delta\models\,G}{%
\begin{array}[t]{ll}
\Delta,\,k_1=k_2,\,e = v &\models G \\
\Delta,\,k_1\neq k_2,\,e = a[k_2] &\models G
\end{array}} $$

\paragraph{Choice} Select a Goal Alternative\\
When the goal is a disjunction, the user select one alternative and discard the others:
$$ \TACTIC{\Delta\models\,\Gamma,G}{\Delta\models\,G} $$

\paragraph{Compound} Decompose compound equalities\\
When the user select an equality between two records, it is decomposed field by field.

$$ \TACTIC{ a = b }{ \bigwedge a.f_i = b.f_i } $$


\paragraph{Contrapose} Swap and Negate Hypothesis with Conclusion\\
The user select a hypothesis (typically, a negation) and swap it with the goal.
$$ \TACTIC{\Delta,H\models\,G}{\Delta,\neg G\models\,\neg H} $$

\paragraph{Cut} Use Intermerdiate Hypothesis
The user introduce a new clause $C$ with the composer to prove the goal. There two variants of the tactic, made available by a menu in the tactic panel.

The \textsf{Modus-Ponens} variant where the clause $C$ is used as an intermediate proof step:

$$\TACTIC{\Delta\models\,G}{%
\begin{array}[t]{ll}
\Delta &\models C \\
\Delta,C &\models G
\end{array}} $$

And the \textsf{Case Analysis} variant where the clause $C$ is used with a split:
$$\TACTIC{\Delta\models\,G}{%
\begin{array}[t]{ll}
\Delta,\phantom{\neg}C \models G \\
\Delta,\neg C \models G
\end{array}} $$

\paragraph{Filter} Erase Hypotheses \\
The tactic is always applicable. It removes hypotheses from the goal on a variable used basis. When variables are compounds (record and arrays) a finer heuristics is used to detect which parts of the variable is relevant. A transitive closure of dependencies is also used. However, it is always possible that too many hypotheses are removed.

The tactic also have a variant where only hypotheses \emph{not relevant} to the goal are retained. This is useful to find absurd hypotheses that are completely disjoint from the goal.

\paragraph{Havoc} Go Through Assigns \\
This is a variant of the \texttt{Lemma} tactic dedicated to \texttt{Havoc} predicate generate by complex assigns clause. The user select an address, and if the address is not assigned by the \texttt{Havoc} clause, the memory at this address is unchanged.

\paragraph{Instance} Instantiate properties\\
The user selects a hypothesis with one or several $\forall$ quantifiers, or an $\exists$ quantified goal. Then, with the composer, the use choose to instantiate one or several of the quantified parameters. In case of $\forall$ quantifier over integer, a range of values can be instantiated instead.

When instantiating hypothesis with an expression $e$:
$$\TACTIC{\Delta,\,\forall x\, P(x)\models G}{\Delta,P(e)\models G}$$

When instantiating with a range of values $n\ldots m$:
$$\TACTIC{\Delta,\,\forall x\, P(x)\models G}{\Delta,P(n)\ldots P(m)\models G}$$

When instantiating a goal with an expression $e$:
$$\TACTIC{\Delta\models \exists x\,G(x)}{\Delta\models G(e)}$$

\paragraph{Lemma} Search \& Instantiate Lemma\\
The user start by selecting a term in the goal. Then, the search button in the tactic panel will display a list of lemma related to the term. Then, he can instantiate the parameters of the lemma, like with the Instance tactic.

\paragraph{Intuition} Decompose with Conjunctive/Disjunctive Normal Form\\
The user can select a hypothesis or a goal with nested conjunctions and disjunctions. The tactics then computes the conjunctive or disjunctive normal form of the selection and split the goal accordingly.

\paragraph{Range} Enumerate a range of values for an integer term\\
The user select any integer expression $e$ in the proof, and a range of numerical values $a\ldots b$. The proof goes by case for each $e=a\ldots e=b$, plus the side cases $e<a$ and $e>b$:
$$\TACTIC{\Delta\models\,G}{%
\begin{array}[t]{ll}
\Delta,e<a &\models G \\
\Delta,e=a &\models G \\
&\vdots \\
\Delta,e=b &\models G \\
\Delta,e>b &\models G
\end{array}} $$

\paragraph{Rewrite} Replace Terms\\
This tactic uses an equality in a hypothesis to replace each occurrence of term by another one.
The tactic exists with two variants: the left-variant which rewrites $a$ into $b$ from equality $a=b$,
and the right-variant which rewrites $b$ into $a$ from equality $a=b$.
The original equality hypothesis is removed from the goal.

$$\TACTIC{\Delta,a=b\models\,G}{\Delta[a\leftarrow b]\models\,G[a\leftarrow b]}$$

\paragraph{Separated} Expand Separation Cases\\
This tactic decompose a \texttt{separated}$(a,n,b,m)$ predicate into its four base cases: $a$ and $b$ have different bases, $a+n \leq b$, $b+m \leq a$, and $a[0..n-1]$ and $b[0..m-1]$ overlaps. The regions are separated in the first three cases, and not separated in the overlapping case. This is kind of normal disjunctive form of the separation clause.

\paragraph{Split} Decompose Logical Connectives and Conditionals\\
This is the most versatile available tactic. It decompose merely any logical operator following the sequent calculus rules. Typically:

\[
\begin{array}{c@{\quad\quad}c@{\quad\quad}c}
  \Delta,(H_1\vee H_2)\models G & \triangleright &
     \Delta,H_1 \models G \\
  && \Delta,H_2 \models G \\
  \Delta\models(G_1\wedge G_2) & \triangleright &
     \Delta\models G_1 \\
  && \Delta\models G_2 \\
  \Delta,H?P:Q\models G & \triangleright &
     \Delta,\phantom{\neg}H,P\models G \\
  && \Delta,\neg H,Q\models G \\
  \ldots
\end{array}
\]

When the user selects a arbitrary boolean expression $e$, the tactic is similar to the Cut one:
\[\TACTIC{\Delta\models\,G}{%
\begin{array}[t]{l}
\Delta,\phantom{\neg}e\models G \\
\Delta,\neg e\models G
\end{array}} \]

Finally, when the user select a arithmetic comparison over $a$ and $b$, the tactics makes a split over $a=b$, $a<b$ and $a>b$:
\[\TACTIC{\Delta\models\,G}{%
\begin{array}[t]{ll}
\Delta,a<b&\models G \\
\Delta,a=b&\models G \\
\Delta,a>b&\models G
\end{array}} \]

\paragraph{Definition} Unfold predicate and logic function definition\\
The user simply select a term $f(e_1,\ldots,e_n)$ or a predicate $P(e_1,\ldots,e_n)$ which is replaced by its definition, when available.

\paragraph{Bitwise} Decompose equalities over $N$-bits\\
The use selects an integer equality and a number of bits.
Providing the two members of the equality are in range $0..2^N-1$,
the equality is decomposed into $N$ bit-tests equalities:
\[\TACTIC{\Delta\models G}{%
\begin{array}[t]{rcl}
\Delta\phantom{)} &\models & 0 \leq a,b < 2^N \\
\sigma(\Delta) & \models & \sigma(G) 
\end{array}
}\]
where $\sigma$ is the following subsitution:
\[ \sigma \equiv 
\left[ a=b \quad \leftarrow 
\bigwedge_{k\in 0..N-1} \mathtt{bit\_test}(a,k) = \mathtt{bit\_test}(b,k)
\right]
\]

The \lstinline{bit_test(a,b)} function is predefined in \textsf{WP} and is equivalent
to the \textsf{ACSL} expression \lstinline{(a & (1 << k)) != 0}. The
\textsf{Qed} engine has many simplification rules that applies to
such patterns, and the a tactic is good way to reason over bits.

\paragraph{Shift} Transform logical shifts into arithmetics\\
For positive integers, logical shifts such as \lstinline{a << k} 
and \lstinline{a >> k} where \lstinline$k$ is a constant can be interpreted into a multiplication or a division by $2^k$.

When selecting a logical-shift, the tactic performs:
\[\TACTIC{\Delta\models G}{%
\begin{array}[t]{rcl}
\Delta\phantom{)} &\models& 0 \leq a \\
\sigma(\Delta) &\models& \sigma(G) 
\end{array}
}\]
where:
\begin{tabular}[t]{ll}
$\sigma = [ \mathtt{lsl}(a,k) \leftarrow a * 2^k ]$ &
for left-shift, \\
$\sigma = [ \mathtt{lsr}(a,k) \leftarrow a / 2^k ]$ &
for right-shifts.
\end{tabular}

\paragraph{BitRange} Range of logical bitwise operators \\
This tactical applies the two following lemmas to the current goal.
The first lemma is on logical-or, and only applies to positive integers:
\[
\begin{array}{c}
  \bigwedge_i 0 \leq x_i < 2^p
  \\\hline
  0 \leq \mathtt{lor}(x_1,\ldots,x_n) \leq 2^p
\end{array}
\]

The second lemma is on logical-and, and applies to at-least one positive integer:
\[
\begin{array}{c}
  \bigvee_i 0 \leq x_i \quad\wedge\quad \bigwedge_i x_i \leq 2^p
  \\\hline
  0 \leq \mathtt{land}(x_1,\ldots,x_n) \leq 2^p
\end{array}
\]

The tactical rewrites range goals on logical and/or into the corresponding range over its parameters, by finding a suitable $2^p$
to apply the theorems. Such a strategy is \emph{not} complete in general.
Typically, $\mathtt{land}(x,y) < 38$ is true whenever both $x$ and $y$ are in range $0\ldots 31$, but this is also true
in other cases.

\paragraph{Congruence} Simplify Divisions and Products \\
This tactic rewrites integer comparisons involving products and divisions.
The tactic applies one of the following theorems to the current goal.
In the following lemmas, $k$, $k'$, and $n$ are integer constants, $a$ and $b$ any integer terms.
The notation $k|n$ stands for $k$ divides $n$.
The lemmas are extended to non-strict inequalities and non-positive constants in a natural way.
\[
\begin{array}{crcl}
0<k, & a < n/k &\Longrightarrow& k.a < n \\
k|n, & a = n/k &\Longleftrightarrow& k.a = n \\
\neg(k|n), & k.a = n & \Longrightarrow & \mathtt{false} \\
0<k, & a < k.(b+1) &\Longrightarrow& a/k < b \\
0<k, 0<k', & k'.a < k.b &\Longrightarrow& a/k < b/k' \\
n|k, n|k', & (k/n).a = (k'/n).b &\Longleftrightarrow& k.a = k'.b 
\end{array}
\]

\paragraph{Overflow} Integer Conversions \\
This tactic rewrites machine integer conversions by identify,
providing the converted value is in available range. The tactic applies on expression
with pattern $\mathtt{to\_iota(e)}$ where \texttt{iota} is a a machine-integer name,
\emph{eg.} \texttt{to\_uint32}.

\[\TACTIC{\Delta\models G}{%
\begin{array}[t]{rcl}
\Delta\phantom{)} &\models & a \leq e \leq b \\
\sigma(\Delta) & \models & \sigma(G) 
\end{array}
}\]
where $\sigma = [ \mathtt{to\_iota}(e) \mapsto e ]$ and $[a..b]$ is the range
of the \texttt{iota} integer domain.

\subsection{Strategies}

Strategies are heuristics that generate a prioritized bunch of tactics to be tried on the current goal.
Few built-in strategies are provided by the WP plug-in ; however, the user can extends the proof editor with
custom ones, as explained in section~\ref{wp-custom-tactics} below.

To run strategies, the interactive proof editor provide a single button \texttt{Strategies} in the tactic panel.
Configure the heuristics you want to include in your try, then click the button. The generated with highest priority is immediately applied. The proof summary now display \texttt{backtrack} buttons revealing proof nodes where alternative tactics are available. You can use those backtracking button to cycle over the generated tactics.

Of course, strategies are meant to be used multiple times, in sequence. Recall that strategies apply highest priority tactic first, on the current goal. When using strategies several times, you shall see several \texttt{backtrack}ing buttons in your proof script. You backtrack from any point at any time.

You shall also alternate strategies \emph{and} manually triggered tactics. Though, strategies are only used to
\emph{infer} or \emph{suggest} interesting tactics to the user. Once your are finished with your proved, only the tactics are saved in the script, not the strategies used to find them. Hence, replaying a script generated with strategies would not involve backtracking any more. The script will directly replay your chosen alternatives.

It is also possible to call strategies from the command line, with option \texttt{-wp-auto}. The strategies are tried up to some depth, and while a limited number of pending goals
remains unproved by \textsf{Qed} or the selected provers. More precisely:
\begin{description}
\item[\tt -wp-auto s,...] applies strategies \texttt{s,...} recursively to unproved goals.
\item[\tt -wp-auto-depth <$n$>] limit recursive application of strategies to depth $n$ (default is 5).
\item[\tt -wp-auto-width <$n$>] limit application of strategies when there is less than $n$ pending goals (default is 10).
\item[\tt -wp-auto-backtrack <$n$>] when the first tried strategies do not close a branch, allows for backtracking
  on $n$ alternative strategies. Backtracking is performed on goals which are closed to the root proof obligation, hence
  performing a kind of width-first search strategy, which tends to be more efficient in practice.
  Backtracking is deactivated by default ($n=0$) and only used when \verb+-wp-auto+ is set.
\end{description}

The name of registered strategies is printed on console by using \texttt{-wp-auto '?'}. Custom strategies can be loaded by plug-ins, see below.

\subsection{Custom Tactics and Strategies}
\label{wp-custom-tactics}

The proof editor and script runner can be extended by loading additional plug-ins. These plug-ins are regular OCaml files to be loaded with the kernel \texttt{-load-module} option. They will be compiled by \textsf{Frama-C} against its API. The \textsf{WP} plug-in exports a rich API to extend the proof editor with new tactics, strategies, and even term-composer tools.

It is not possible to reproduce here the complete API ; it is better to use the automatically generated HTML documentation from WP's sources. We only provide here a quick tour of this API, as a tutorial on how to implement a basic custom strategy.

The main extension points of the \textsf{WP} plug-in's API are the following ones:
\begin{center}
    \begin{tabular}{ll}
    \hline
    \texttt{Wp.Tactical.tactical} & Base-class definition of custom Tactic. \\
    \texttt{Wp.Strategy.heuristic} & Base-class definition of custom Strategy. \\
    \hline
    \texttt{Wp.Auto.$\star$} & Pre-defined tactics and strategies. \\
    \texttt{Wp.Tactical.register} & Registration point for custom Tactics. \\
    \texttt{Wp.Strategy.register} & Registration point for custom Strategies. \\
    \texttt{Wp.Tactical.add\_composer} & Registration point for custom term composer. \\
    \hline
    \end{tabular}
\end{center}

\paragraph{Warning:} It is technically possible to break the logical soundness of \textsf{WP} when using custom tactics crafted by hand. Fortunately, using only pre-defined tactics in custom strategies will be always safe, even if your heuristic generates crazily stupid alternatives to solve a goal. The point with custom \emph{tactics} is that you might transform a sequent \emph{without preserving} the equivalence with the original goal if you make some mistakes into your custom code. This is the same problem as using \textsf{ACSL} axioms instead of lemmas. So, use custom tactics carefully, and prefer custom strategies when possible.

To build a custom strategy, the typical boilerplate code is as follows:
\begin{lstlisting}[language=ocaml]
 (* file: dummy.ml *)
open Wp

class dummy : Strategy.heuristic =
object
    method id = "MyStrategy.dummy" (* required, must be unique *)
    method title = "Split Goal"    (* visible in Strategy panel *)
    method descr = "Simply split conjunctions in goal" (* idem *)
    method search push sequent = (* heuristic code *)
      let goal = snd sequent in
      match Repr.pred goal with
      | And _ ->
          let selection = Tactical.(Clause(Goal goal)) in
          push (Auto.split ~priority:2.0 selection)
      | _ -> ()
end

(* Register the strategy *)
let () = Strategy.register (new dummy)
\end{lstlisting}

Then, simply extend your command line with the following options to make your strategy available from the interactive proof editor:
\begin{logs}
> frama-c-gui -load-module dummy.ml [...]   
\end{logs}

\paragraph{Note:} Loading custom strategies is only required when running the graphical user interface (\texttt{frama-c-gui}). When replaying scripts from the command line (\texttt{frama-c}), only custom tactics and custom composers actually involved in proofs are required to be loaded.

The example custom strategy above is structured as follows. First we open the module \lstinline$Wp$ to simplify
access to the API. A custom strategy must be an instance of class-type \lstinline$Strategy.heuristic$, and we use a coercion here to explicit types. Methods \lstinline$#id$, \lstinline$#title$ and \lstinline$#descr$ are required and describes the strategy, making it available from the tactic panel in the graphical user interface. 

The actual heuristic code takes place in method \lstinline$#search$ which has the following type (consult the html API for details):
\begin{lstlisting}[language=ocaml]
    method search : (Strategy.strategy -> unit) -> Conditions.sequent -> unit
\end{lstlisting}

This method takes two parameters: a strategy registration callback and the sequent to prove. Each heuristic
is supposed to register any number of strategies to be tried on the provided sequent. In turn, each strategy 
is a record consisting of a priority, a tactic, a target selection for the tactic and its arguments.
It is possible to build such a record by hand, using custom or predefined tactics. However, it is much more convenient
to use the helper functions from module \lstinline$Auto$ that directly build strategies.

In the example above, we inspect the structure of the goal, and when a conjunction is detected (\lstinline$And _$), 
we decide to register a split tactic, thanks to the helper function \lstinline$Auto.split$. Default priority is \lstinline$1.0$ by convention. Pre-installed strategies would only use range $[0.5\ldots2.0]$ of priorities. You can use any value you want inside or outside this range. In the example below, we assign a high priority to the split of goal conjunctions, meaning that such a split should be tried first.

\paragraph{Using Selections.} Tactics always need a \lstinline$selection$ target. Moreover, some tactics require additional parameters, also to be provided as \lstinline$selection$ values. Typically, consider the \lstinline$Auto.range$ tactic:

\begin{lstlisting}{language=ocaml}
   val Auto.range : ?priority:float -> selection -> vmin:int -> vmax:int -> strategy
\end{lstlisting}

Here the selection argument shall targets the expression to be enumerated in range \lstinline$vmin..vmax$.
Selections must refer to a term that pre-exists in the sequent. You must indicate to the \textsf{WP} proof engine
how to rebuild this term from the sequent. Hence, if the \textsf{C}-code or the \textsf{ACSL} specification change,
\textsf{WP} still has a chance to rebuild the same selection from the updated sequent.

Selections are easy to build. There are five basic forms, as described below:
\begin{lstlisting}[language=ocaml]
   type Tactical.selection =
     | Empty (** no selection *)
     | Clause of clause (** selects a full hypothesis or the full goal *)
     | Inside of clause * Lang.F.term (** selects a sub-term of a hypothesis or goal *)
     | Compose of compose (** a calculus from several sub-selections *)
   and Tactical.clause =
     | Goal of Lang.F.pred
     | Step of Conditions.step
\end{lstlisting}

It is also possible to build selections from sequent by explicit lookup:
\begin{lstlisting}[language=ocaml]
   val Strategy.select_e : Conditions.sequent -> Lang.F.term -> Tactical.selection
   val Strategy.select_p : Conditions.sequent -> Lang.F.pred -> Tactical.selection
\end{lstlisting}

Composition allows you to build new terms from existing ones, like when using the term composer from the graphical user interface. You access composers by their name, like in the term composer. The API for building new terms is as follows:
\begin{lstlisting}[language=ocaml]
   val Tactical.int : int -> Tactical.selection
   val Tactical.cint : Integer.t -> Tactical.selection
   val Tactical.range : int -> int -> Tactical.selection
   val Tactical.compose : string -> Tactical.selection list -> Tactical.selection
\end{lstlisting}

For instance, provided you have two selected terms \lstinline$a$ and \lstinline$b$, you can build their sum using
\lstinline$compose "wp:add" [a;b]$. The name of composers can be obtained from the graphical user interface.

\paragraph{Exploring Sequents.}
The clauses refer to parts of the provided sequent. Typically, a sequent consists of a
sequence of hypothesis, and a goal to prove. Each hypothesis is represented by a \lstinline$step$, consisting either of single hypothesis or a more structured condition
(branch, cases, \textit{etc}.):

\begin{lstlisting}[language=ocaml]
   type Conditions.sequent = sequence * Lang.F.pred
   and  sequence = .... step list ... (* private type *)
   and  step = { condition : condition ; ... }
   and  condition =
           | Have of Lang.F.pred (** hypothesis *)
           | Init of Lang.F.pred (** C-initializer initialization clause *)
           | Type of Lang.F.pred (** C/ACSL type constraints *)
           | Core of Lang.F.pred (** Common hypothesis factorization from WP *)
           | When of Lang.F.pred (** hypothesis from tactical or simplification *)
           | Branch of Lang.F.pred * sequence * sequence (** If-Then-Else *)
           | Either of sequence list (** Disjunction of Cases *)
   val iter : (step -> unit) -> sequence -> unit
\end{lstlisting}

When you walk through a sequence of hypothesis, you shall reuse the provided steps to build clauses and selections.

\paragraph{Exploring Formulae}.
The constituent of hypothesis and goals are logical terms and predicates. You shall use
module \lstinline$Repr.term$ and \lstinline$Repr.pred$ to access the internal representation
of formulae. There are many constructors for terms and predicates, simply browse the html documentation to have an overview. Many properties about terms and predicates are directly obtained from the \lstinline$Lang.F$ module. The API is quite rich, so use the html documentation to get details.

\clearpage
%-----------------------------------------------------------------------------
\section{Command Line Options}
\label{wp-cmdline}
%-----------------------------------------------------------------------------

The best way to know which options are available is to use:
\begin{shell}
# frama-c -wp-help
\end{shell}

The \textsf{WP} plug-in generally operates in three steps:
\begin{enumerate}
\item Annotations are selected to produce a control-flow graph of
  elementary statements annotated with hypotheses and goals.
\item Weakest preconditions are computed for all selected goals in the
  control-flow graph. Proof obligations are emitted and saved on disk.
\item Decision procedures (provers) are run to discharge proof obligations.
\end{enumerate}

The \textsf{WP} options allow to refine each step of this process. It
is very convenient to use them together with the standard \texttt{-then}
option of \textsf{Frama-C}, in order to operate successive passes on the project.
See section~\ref{wp-persistent} for details.

\subsection{Goal Selection}

This group of options refines the selection of annotations for which
proof obligations are generated. By default, all annotations are
selected. A property which is already proved -- by \textsf{WP} or by
any other plug-in -- does not lead to any proof-obligation generation,
unless the property is individually selected from the graphical user
interface of the programmatic API.

\begin{description}
\item [\tt -wp] generates proof obligations for all (selected) properties.
\item [\tt -wp-fct <f$_1$,...,f$_n$>] selects annotations of functions
  \texttt{f$_1$},...,\texttt{f$_n$} (defaults to all functions).
\item [\tt -wp-skip-fct <f$_1$,...,f$_n$>] removes annotations of
  functions \texttt{f$_1$},...,\texttt{f$_n$} (defaults to none).
\item [\tt -wp-bhv <b$_1$,...,b$_n$>] selects annotations for behaviors
  \texttt{b$_1$},...\texttt{b$_n$} (defaults to all behaviors) of the
  selected functions.
\item [\tt -wp-prop <p$_1$,...,p$_n$>] selects properties having
  \texttt{p$_1$} or ...\texttt{p$_n$} as tagname (defaults to all
  properties). You may also replace a tagname by a
    \texttt{@<category>} of properties.
    \\
    Recognized categories are: \texttt{@lemma}, \texttt{@requires}, \texttt{@assigns},
    \texttt{@ensures}, \texttt{@exits},  \texttt{@assert},
    \texttt{@invariant}, \texttt{@variant}, \texttt{@breaks},
    \texttt{@continues}, \texttt{@returns}, \\
    \texttt{\mbox{@complete\_behaviors}}, \texttt{\mbox{@disjoint\_behaviors}}.
    \\ 
    Properties can be prefixed with a minus sign to \emph{skip} the associated annotations.
    For example \texttt{-wp-prop="-@assigns"} removes all \texttt{assigns} 
    and \texttt{loop assigns} properties from the selection.
\item [\tt -wp-(no)-status-all] includes in the goal selection all properties
  regardless of their current status (default is: \texttt{no}).
\item [\tt -wp-(no)-status-valid] includes in the goal selection those properties
  for which the current status is already 'valid' (default is: \texttt{no}).
\item [\tt -wp-(no)-status-invalid] includes in the goal selection those properties
  for which the current status is already 'invalid' (default is: \texttt{no}).
\item [\tt -wp-(no)-status-maybe] includes in the goal selection those properties with
  an undetermined status (default is: \texttt{yes}).
\end{description}

\textbf{Remark:} options \texttt{-wp-status-xxx} are not taken into account
when selecting a property by its name or from the GUI.

\subsection{Program Entry Point}

The generic \textsf{Frama-C} options dealing with program entry point
are taken into account by \textsf{WP} plug-in as follows:

\begin{description}
\item [\tt -main <f>] designates \texttt{f} to be the main entry point (defaults to \texttt{main}).
\item [\tt -lib-entry] the main entry point (as defined by option
\texttt{-main}) is analyzed regardless of its initial context (default is no).
\end{description}

These options impact the generation of proof-obligations for the
``\texttt{requires}'' contract of the main entry point. More precisely, if there
is a main entry point, \emph{and} \texttt{-lib-entry} is not set:
\begin{itemize} 
\item the global variables are set to their initial values at the
  beginning of the main entry point for all its properties to be established;
\item special proof obligations are generated for the preconditions of the
  main entry point, hence to be proved with globals properly initialized.
\end{itemize}

Otherwise, initial values for globals are not taken into account and
no proof obligation is generated for preconditions of the main entry
point.

\subsection{Model Selection}
These options modify the underlying memory model that is used for
computing weakest preconditions. See chapter~\ref{wp-models} for
details. Models are identified by a combination of \emph{selectors}
which are defined below:
\begin{center}
  \begin{tabular}{cl}
    Selector & Description \\
    \hline
    \texttt{\bf Hoare} & Select Hoare memory model. \\
    \texttt{\bf Typed} & Select Typed memory model with limited casts.\\
    \texttt{cast}  & Select Typed memory model with unlimited casts (unsound). \\
    \texttt{nocast} & Select Typed memory model with \emph{no} casts. \\
    \hline
    \texttt{raw} & Disable the combination of memory models. \\
    \texttt{var} & Combination of memory models based on variable analysis. \\
    \texttt{ref} & Activate the detection of pointer variables used for reference passing style. \\
    \texttt{caveat} & Caveat memory model (see~\ref{CAVEAT}). \\
    \hline
    \texttt{int} & Use machine integers when overflows and downcasts might occurs. \\
    \texttt{nat} & Integer model without bounds (no overflow assumed). \\
    \hline
    \texttt{float} & Use floating-point operations. \\
    \texttt{real} & Use mathematical reals instead of floating point. \\
    \hline
  \end{tabular}
\end{center}

Refer to Section~\ref{wp-model-arith} for details on arithmetic models and
Chapter~\ref{wp-models} for a description of memory models.

The available \textsf{WP} command-line options related to model selection are:
\begin{description}
\item[\tt -wp-model <spec...>] specifies the models to use. The
  specification is a list of \emph{selectors}. Selectors are usually
  separated by `\verb|,|' although other separators are accepted as well:
  `\verb|+|', `\verb|_|', spaces, newlines, tabs and parentheses `\verb|(|',
  `\verb|)|'.\\ Selectors are \emph{case insensitive}. The option
  \texttt{-wp-model} can be used several times. All provided selectors
  are processed from left to right, possibly canceling previous ones.\\
  Default setting corresponds to \texttt{-wp-model "Typed+var+int+float"}.

\item[\tt -warn-(un)signed-(overflow|downcast)] those kernel options are
  used by the (default) arithmetic model \texttt{-wp-model +int} to interpret integer
  arithmetic. See section~\ref{wp-model-arith} for details.

\item[\tt -wp-(no)-overflows] explicitly add to proof context the assumptions related
  to overflows and downcasts selected. This is especially useful when casts are inserted
  in \textsf{ACSL} contracts to ensure type-checking but are related to identity-casts
  from the code. The option is \texttt{off} by default.

\item[\tt -wp-bool-range] experimental support for \verb+_Bool+ range. This option assumes
  there is no \emph{trap representations}
  in considering valid the related assertions generated by \texttt{-wp-rte} (those tagged with \texttt{bool\_value:}).
  Hence, integer values with boolean type are
  either equal to \verb+0+ or \verb+1+. Actually, the only way to forge other values
  is \emph{via} union types and heterogeneous pointer casts, which is currently not allowed
  in the memory models of \textsf{WP}.

\item[\tt -wp-literals] exports the contents of string literals
  to provers (default: \texttt{no}).
\item[\tt -wp-extern-arrays] gives an arbitrary large size to arrays
  with no dimensions. This is a model of infinite size arrays
  (default is: \texttt{no}).
\item[\tt -wp-(alias|unalias|ref|context)-vars <var,...>] these options can be used
  to finely tweak the memory model inferred by \textsf{WP}. Each variable with a given name
  can be forced to be modeled as follows:\\[1ex]
  \begin{tabular}{rl}
      \texttt{alias}: & the variable is known to have aliases and modeled by \texttt{Typed}.\\
      \texttt{noalias}: & the variable is known to have \emph{no} alias and modeled with \texttt{Hoare}.\\
      \texttt{ref}: & the variable is a constant pointer and is modeled by the \texttt{Ref}.\\
      \texttt{context}: & the variable is initially non-aliased and uses a fresh global in \texttt{Typed}.\\
  \end{tabular}
\item[\tt -wp-(no)-volatile] this option (de)activate the correct handling of
  volatile access. By default, accessing a volatile l-value returns an undefined
  value, and writing to a volatile l-value is modeled like an \textsf{ACSL} assigns clause.
  Hence, only the accessed \emph{values} are ignored.\\
  Setting \texttt{-wp-no-volatile} turns this behavior off: it is potentially \emph{unsound} and
  makes the \textsf{WP} emitting a warning on each volatile access.
\item[\tt -wp-(no)-warn-memory-model] this option (de)activate the
  warnings about memory model hypotheses
  for the generated proof obligations. For each model supporting this feature, and each concerned function,
  an \textsf{ACSL} specification is printed on output.
  Currently, only the \texttt{Caveat}, \texttt{Typed} and \texttt{Ref} memory models support
  this feature.
\end{description}

\subsection{Computation Strategy}

These options modify the way proof obligations are generated during
weakest precondition calculus.

\begin{description}
\item[\tt -wp-(no)-rte] generates RTE guards before computing weakest
  preconditions. This option calls the \emph{rte generation} plug-in
  before generating proof obligations.
  The generated guards, when proved\footnote{It is still correct to prove these RTE
    annotations with the \textsf{WP} plug-in.}, fulfill the requirements for
  using the \textsf{WP} plug-in with the default machine-integer domain (default is: \texttt{no}).
  Using this option with \texttt{-wp-model nat} is tricky, because \texttt{rte} uses the kernel options
  to generate guards, and they might be not strong enough to meet the natural model requirements.
  In this case, a warning is emitted for potential runtime errors.
  Refer to Section~\ref{wp-model-arith} for details.
\item[\tt -wp-(no)-split] conjunctions in generated proof obligations are
  recursively split into sub-goals.  The generated goal names are
  suffixed by ``{\tt part<{\it n}>}'' (defaults to \texttt{no}).
\item[\tt -wp-(no)-callee-precond] includes preconditions of the callee
  after\footnote{Proof obligations are always generated to check preconditions.}
  a call (default is: \texttt{yes}).
\item[\tt -wp-(no)-unfold-assigns] prove assigns goal of \texttt{struct}
  compound types field by field. This allows for proving that assigning
  a complete structure is still included into an assignment field by field.
  This option is not set by default, because it is generally not necessary
  and it can generates a large number of verifications for structures
  with many (nested) fields (defaults to \texttt{no}).
\item[\tt -wp-(no)-dynamic] handles calls \textit{via} function pointers
  thanks to the dedicated \verb+@calls f1,...,fn+ code annotation.
  For each call to a function pointer \texttt{fp}
  in the instruction or block under the annotaion,
  \texttt{fp} is required to belongs to the set \texttt{f1,\ldots,fn} and
  a case analysis is performed with the contract of each provided function
  (default is: \texttt{yes}).
925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538
\end{description}

\subsection{Trigger Generation}
\label{triggers}

The \textsf{ACSL} language does not provide the user with a syntax for
declaring \emph{triggers} associated to lemmas and axioms. However,
triggers are generally necessary for \textsf{SMT} solvers to discharge
efficiently the generated proof obligations.

There is a limited support for triggers in \textsf{WP}. The
\emph{sub-terms} and \emph{sub-predicates} marked with label
\verb+"TRIGGER"+ in an axiom or lemma are collected to generate a
multi-trigger for their associated free variables.

\subsection{Qed Simplifier Engine}

These options control the simplifications performed by the \textsf{WP} plug-in before
sending proof obligations to external provers. The default simplifiers can be
controlled by the following options:

\begin{description}
\item[\tt -wp-(no)-simpl] simplifies constant
  expressions and tautologies (default is: \texttt{yes}).
\item[\tt -wp-(no)-let] propagates equalities by substitutions 
  and let-bindings (default is: \texttt{yes}).
\item[\tt -wp-(no)-core] factorize common properties between branches
  (default is: \texttt{yes}).
\item[\tt -wp-(no)-pruning] eliminates trivial branches of conditionals
  (default is: \texttt{yes}).
\item[\tt -wp-(no)-clean] removes unused terms and variables from
  proof obligations (default is: \texttt{yes}).
\item[\tt -wp-(no)-ground] replace ground values in equalities
  (default is: \texttt{yes}).
\item[\tt -wp-(no)-reduce] replace functions with precedence to constructors and
  operators (default is: \texttt{yes}).
\item[\tt -wp-(no)-parasite] eliminate parasite variables
  (default is: \texttt{yes}).
\item[\tt -wp-(no)-bits] simplifies bitwise operations
  (default is: \texttt{yes}).
\item[\tt -wp-(no)-init-summarize-array] summarize contiguous initializers
  with quantified formulae (default: \texttt{yes}).
\item[\tt -wp-(no)-simplify-is-cint] eliminates redundant constraints on integers 
  (default: \texttt{yes}).
\item[\tt -wp-(no)-simplify-land-mask] tight constants in logical-and with
  unsigned integers (default: \texttt{yes}).
\item[\tt -wp-(no)-prenex] normalize nested quantifiers into prenex-form
  (default: \texttt{no}).
\item[\tt -wp-(no)-simplify-forall] eliminates integer ranges in quantifiers
  (\emph{unsound}, to be used with caution, default is: \texttt{no}).
\item[\tt -wp-(no)-simplify-type] remove type constraints from proof obligation
  (\emph{incomplete}, default is: \texttt{no}).
\item[\tt -wp-bound-forall-unfolding <n>] instantiates statically \texttt{n}
  instances of $k$ for hypothesis $\forall k \in [n_1..n_2], a = b$
  (default is: \texttt{1000}).
\end{description}

\subsection{Decision Procedures Interface}
\label{wp-provers}

The generated proof obligations are submitted to external decision
procedures.  If proof obligations have just been generated, by using
\texttt{-wp}, \texttt{-wp-fct}, \texttt{-wp-bhv} or \texttt{-wp-prop},
then only the new proof obligations are sent. Otherwise, all unproved
proof obligations are sent to external decision procedures.

\begin{description}
\item[\tt -wp-prover <dp,...>] selects the decision procedures used to
  discharge proof obligations. See below for supported provers.  By
  default, \texttt{alt-ergo} is selected, but you may specify another
  decision procedure or a list of to try with.  Finally, you should
  supply \texttt{none} for this option to skip the proof step.

  It is possible to ask for several decision procedures to be tried.
  For each goal, the first decision procedure that succeeds cancels the
  other attempts.
\item[\tt -wp-proof <dp,...>] \textbf{deprecated} alias for \texttt{-wp-prover} for
  backward compatibility with \textsf{WP} version \verb+0.6+.
\item[\tt -wp-gen] only generates proof obligations, does not run provers.
  See option \texttt{-wp-out} to obtain the generated proof obligations.
\item[\tt -wp-par <n>] limits the number of parallel process runs for
  decision procedures. Default is 4 processes. With
  \texttt{-wp-par~1}, the order of logged results is fixed. With more
  processes, the order is runtime dependent.
\item[\tt -wp-filename-truncation <n>] truncates the basename of proof
  obligation files to the first \texttt{n} characters.
  Since numbers can be added as suffixes to ensure unique filenames,
  their length can be longer than \texttt{n}.
  No truncation is performed when the value equals zero.
\item[\tt -wp-(no)-proof-trace] asks for provers to output extra information
  on proved goals when available (default is: \texttt{no}).
\item[\tt -wp-(no)-unsat-model] asks for provers to output extra information
  when goals are not proved (default is: \texttt{no}).
\item[\tt -wp-timeout <n>] sets the timeout (in seconds) for the calls
  to the decision prover (defaults to 10 seconds).
\item[\tt -wp-time-extra <n>] additional time allocated to provers when
  replaying a script. This is used to cope with variable machine load.
  Default is \verb+5s+.
\item[\tt -wp-time-margin <n>] margin time for considering a proof to be
  replayable without a script. When a proof succeed within \verb+timeout-margin+
  seconds, it is considered fully automatic. Otherwise, a script is created
  by prover \verb+tip+ to register the proof time. This is used to decrease the
  impact of machine load when proof time is closed to the timeout.
  Default is \verb+5s+.
\end{description}

\hrule
\paragraph{Alt-Ergo.}
Direct support for the \textsf{Alt-Ergo} prover is provided. You need at least
version \verb+0.99+ of the prover, but more recent versions \verb+1.01+ or
\verb+1.30+ are preferrable. It is also the default selected prover.
\begin{description}
\item[\tt -wp-prover alt-ergo] selects \textsf{Alt-Ergo}.
\item[\tt -wp-prover altgr-ergo] opens the graphical interface of
  \textsf{Alt-Ergo} when the goal is not proved.
\item[\tt -wp-steps <$n$>] sets the maximal number of \textsf{Alt-Ergo} 
  steps. This can be used as a machine-independent alternative to timeout.
\item[\tt -wp-depth <$n$>] sets '\textit{stop}' and
  '\textit{age-limit}' parameters of \textsf{Alt-Ergo} such that $n$ cycles of
  quantifier instantiations are enabled.
\item[\tt -wp-alt-ergo-opt <opt,...>] passes additional options to \textsf{Alt-Ergo}
  (default: none).
\item[\tt -wp-alt-ergo='<cmd>'] override the \verb+alt-ergo+ command.  
\item[\tt -wp-altgr-ergo='<cmd>'] override the \verb+altgr-ergo+ command.  
\end{description}

\hrule
\paragraph{Coq.}
Direct support for the \textsf{Coq} proof assistant is provided. The
generated proof obligations are accepted by \textsf{Coq} version \verb+8.4+.
When working with \textsf{Coq}, you will enter an interactive session,
then save the proof scripts in order to replay them in batch mode.

\begin{description}
\item[\tt -wp-prover coq] runs \texttt{coqc} with the default tactic or
  with the available proof script (see below).
\item[\tt -wp-prover coqide] first tries to replay some known proof
  script (if any). If it does not succeed, then a new interactive
  session for \texttt{coqide} is opened. As soon as \texttt{coqide}
  exits, the edited proof script is saved back (see below) and finally
  checked by \texttt{coqc}.\par
  The only part of the edited file retained by \textsf{WP} is the proof script
  between ``\texttt{Proof}\ldots\texttt{Qed.}''.
\item[\tt -wp-script <f.script>] specifies the file which proof scripts
  are retrieved from, or saved to. The format of this file is private to
  the \textsf{WP} plug-in. It is, however, a regular text file from which
  you can cut and paste part of previously written script proofs.
  The \textsf{WP} plug-in manages the content of this file for you.
\item[\tt -wp-(no)-update-script] if turned off, the user's script
  file will \emph{not} be modified. A warning is emitted if the script data base
  changed.
\item[\tt -wp-tactic <ltac>] specifies the \textsf{Coq} tactic to try
  with when no user script is found. The default tactic is
  \verb+"auto with zarith"+. See also how to load external libraries
  and user-defined tactics in section~\ref{prooflibs}.
\item[\tt -wp-tryhints] When both the user-provided script and the
  default tactic fail to solve the goal, other scripts for similar goals can
  be tried instead.
\item[\tt -wp-hints <n>] sets the maximal number of suggested proof scripts.
\item[\tt -wp-coq-timeout <n>] sets the maximal time in seconds for running
  the \texttt{coqc} checker. Does not apply to \texttt{coqide} (default: 30s).
\item[\tt -wp-coq-opt <opt,...>] additional options for \texttt{coqc} and \texttt{coqide}
  (default: none).
\item[\tt -wp-coqc='<cmd>'] override the \verb+coqc+ command.
\item[\tt -wp-coqide='<cmd>'] override the \verb+coqide+ command.
  If the command line contains the \verb+emacs+ word (case-insensitive),
  coq-options are not passed to the command, but a coq-project is used instead.
  This conforms to Proof General 4.3 settings.
  The project file can be changed (see below).
\item[\tt -wp-coq-project='<name>'] override the \verb+_CoqProject+ file name
  for Emacs and Proof General. 
\end{description}

\hrule
\paragraph{Why3.}
Since \textsf{WP} version \verb+0.7+ (Fluorine), native support for \textsf{Why3}
and \textsf{Why3-Ide} are provided. The older system \textsf{Why}
\verb+2.x+ is \emph{no} longer supported.
\begin{description}
\item[\tt -wp-prover "why3ide"] runs \textsf{Why3-Ide} with all
  generated goals.  On exit, the \textsf{WP} plug-in reads back your
  \textsf{Why3} session and updates the proof obligation status accordingly.
\item[\tt -wp-prover "<p>"] runs a \textsf{Why3} prover named \texttt{<p>}.
\item[\tt -wp-prover "why3:<p>"] useful alias when \texttt{"<p>"} can
  be ambiguous. It is actually different to run \texttt{alt-ergo} or \texttt{coq}
  directly from \textsf{WP} or through \textsf{Why3}.
\item[\tt -wp-detect] lists the provers available with \textsf{Why3}.
  This command calls \texttt{why3 --list-provers} but you have to
  configure \textsf{Why3} on your own before, for instance by using
  \texttt{why3config}. Consult the \textsf{Why3} user manual for details.
  The listed prover names can be directly used with the \texttt{-wp-prover} option.
\item[\tt -wp-why3='<cmd>'] override the \verb+why3+ command.
\end{description}

\paragraph{Sessions.}
Your \textsf{Why3} session is saved in the \texttt{"project.session"}
sub-directory of \texttt{-wp-out}. You may run
\texttt{why3ide} by hand by issuing the following command:
\begin{shell}
# why3ide -I <frama-c-share>/wp <out>/project.session
\end{shell}

Proof recovering features of \textsf{Why3} are fully available, and
you can interleave proving from \textsf{WP} with manual runs of
\texttt{why3ide}. Interactive proofs with \textsf{Why3} are completely
separated from those managed by the native \textsf{WP} interface with
\textsf{Coq}.

\subsection{Generated Proof Obligations}
Your proof obligations are generated and saved to several text
files. With the \texttt{-wp-out} option, you can specify a directory
of your own where all these files are generated. By default, this
output directory is determined as follows: in the GUI, it is
\texttt{<home>/.frama-c-wp} where \texttt{<home>} is the user's home
directory returned by the \texttt{HOME} environment variable. In
command-line, a temporary directory is automatically created and
removed when \textsf{Frama-C} exits.

Other options controlling the output of generated proof
obligations are:
\begin{description}
\item[\tt -wp-(no)-print] pretty-prints the generated proof obligations on
  the standard output. Results obtained by provers are reported as
  well (default is: \texttt{no}).
\item[\tt -wp-out <dir>] sets the user directory where proof
  obligations are saved. The directory is created if it does not exist
  yet. Its content is not cleaned up automatically.
\end{description}

\subsection{Additional Proof Libraries}
\label{prooflibs}

It is possible to add additional bases of knowledge to decision
procedures.  This support is provided for \textsf{Alt-Ergo},
\textsf{Why3} and \textsf{Coq} thanks to the following options:
\begin{description}
\item[\tt -wp-share <dir>] modifies the default directory where
  resources are found.  This option can be useful for running a modified or
  patched distribution of \textsf{WP}.
\item[\tt -wp-include <dir,\ldots,++sharedir>] (\textbf{deprecated} use driver instead) sets the directories where external
  libraries and driver files are looked for.
  The current directory (implicitly added to that list) is always looked up
  first.
  Relative directory names are relative to the current directory except 
  for names prefixed by the characters \texttt{++}. 
  In such a name, the directory is relative to the main \texttt{FRAMAC\_SHARE} 
  directory.
\item[\tt -wp-alt-ergo-lib <f,\ldots>] (\textbf{deprecated} use altergo.file
  in driver instead) looks for \textsf{Alt-Ergo}
  library files \verb+"f.mlw"+ and inlines them into the proof
  obligation files for \textsf{Alt-Ergo}.
\item[\tt -wp-coq-lib <f,\ldots>] (\textbf{deprecated} use coq.file
  in driver instead) looks for \textsf{Coq} files
  \verb+"f.v"+ or \verb+"f.vo"+. If
  \verb+"f.vo"+ is not found, then \textsf{WP} copies \verb+"f.v"+
  into its working directory (see option
  \texttt{-wp-out}) and compiles it locally.
\item[\tt -wp-why-lib <f,\ldots>] (\textbf{deprecated} use why3.file in driver instead) looks for \textsf{Why3} library file
  \verb+"f.why"+ and opens the library \verb+"f.F"+ for the proving the
  goals.
\end{description}

\subsection{Linking \textsf{ACSL} Symbols to External Libraries}
\label{drivers}

Besides additional proof libraries, it is also possible to
\emph{link} declared \textsf{ACSL} symbols to external or predefined
symbols. In such case, the corresponding \textsf{ACSL} definitions,
if any, are not exported by \textsf{WP}s.

External linkage is specified in \emph{driver files}. It is possible
to load one or several drivers with the following \textsf{WP} plug-in option:
\begin{description}
\item[\tt -wp-driver <file,\ldots>] load specified driver files,
  replacing deprecated features from section~\ref{prooflibs}.

\end{description}

\newcommand{\ccc}{\texttt{,}\ldots\texttt{,}}
\newcommand{\user}[1]{\texttt{"}\textit{#1}\texttt{"}}
Each driver file contains a list of bindings with the following syntax:
\begin{center}
  \begin{tabular}{|l}
  \texttt{library} \user{lib}\verb':' \user{lib} \ldots \user{lib} \\
  \quad\begin{tabular}{rll}
  \rule{0em}{1.2em}
  \textit{group}.\textit{field} &\texttt{:=} \textit{string} \\
  \textit{group}.\textit{field} &\texttt{+=} \textit{string} \\
  \texttt{type} & \textit{symbol} & \verb'=' \user{link} \verb';' \\
  \texttt{ctor} & \textit{type} \textit{symbol} 
                   \verb'(' \textit{type}\ccc\textit{type} \verb')'
                 & \verb'=' \user{link} \verb';' \\
  \texttt{logic} & \textit{type} \textit{symbol} 
                   \verb'(' \textit{type}\ccc\textit{type} \verb')'
                 & \verb'=' \textit{property-tags} \user{link} \verb';' \\
  \texttt{predicate} & \textit{symbol} 
                   \verb'(' \textit{type}\ccc\textit{type} \verb')'
                 & \verb'=' \user{link} \verb';'
  \end{tabular}
  \end{tabular}
\end{center}

It is also possible to define \emph{aliases} to other ACSL symbols, rather
than external links. In this case, you may replace \verb+=+ by
\verb+:=+ and use an ACSL identifier in place of the external \user{link}.
No property tag is allowed when defining aliases.

Library specification is optional and applies to subsequent linked
symbols. If provided, the \textsf{WP} plug-in automatically loads the
specified external libraries when linked symbols are used in a
goal. Dependencies among libraries can also be specified, after the
'\verb':''.

Generic \textit{group}.\textit{field} options have a specific
value for each theory. The binding applies to the current theory.
Binding with the \verb':=' operator
resets the option to the singleton of the given string
and binding with the \verb'+=' operator
adds the given string to the current value of the option.
The following options are defined by the plugin:
\texttt{coq.file}, \texttt{altergo.file}, \texttt{why3.file} and \texttt{why3.import}.

\textsf{C}-Comments are allowed in the file. For overloaded
\textsf{ACSL} symbols, it is necessary to provide one \user{link} symbol for
each existing signature. The same \user{link} symbol is used for all provers,
and must be defined in the specified libraries, or in the external
ones (see~\ref{prooflibs}).

It is also possible to specify different names 
for each prover, with the following syntax:
\texttt{\{coq=\user{a};altergo=\user{b};why3=\user{c}\}}.
Alternatively, a link-name can be an arbitrary string 
with patterns substituted by arguments, \verb="(%1+%2)"= for instance.

When a library \user{lib} is specified, the loaded module depends on the
target solver:
\begin{center}\tt
  \begin{tabular}{llll}
    & \textrm{Option} & \textrm{Format} \\
    \hline
    \textsf{Coq}: & coq.file & \verb+[dir:]path.v+ \\
    \textsf{Alt-Ergo}: & altergo.file & \verb+path.mlw+ \\
    \textsf{Why3}: & why3.file & \verb+path.why[:name][:as]+ \\
                   & why3.import & \verb+theory[:as]+ \\
  \end{tabular}
\end{center}

Precise meaning of formats is given by the following examples (all filenames are relatives to the driver file's directory):
\begin{description}
\item[\tt coq.file="mydir/bar.v"] Imports module \verb+Bar+ from file \verb+mydir/bar.vo+.
\item[\tt coq.file="mydir/foo:Foo.v"] Loads coq library \verb+foo.Foo+ from file \verb+mydir/foo/Foo.vo+.
\item[\tt why3.file="mydir/foo.why"] Imports theory \verb+foo.Foo+ from directory \verb+mydir+.
\item[\tt why3.file="mydir/foo.why:Bar"] Imports theory \verb+foo.Bar+ from directory \verb+mydir+.
\item[\tt why3.file="mydir/foo.why:Bar:T"] Imports theory \verb+foo.Bar as T+ from directory \verb+mydir+.
\item[\tt why3.import="foo.Bar"] Imports theory \verb+foo.Bar+ with no additional includes.
\item[\tt why3.import="foo.Bar:T"] Imports theory \verb+foo.Bar as T+ with no additional includes.
\end{description}

See also the default \textsf{WP} driver file, in \verb+[wp-share]/wp.driver+.

Optional \textit{property-tags} can be given to
\texttt{logic} \user{link} symbols to allow the WP to perform
additional simplifications (See section~\ref{wp-simplifier}).  Tags
consist of an identifier with column (`\verb+:+'), sometimes followed
by a link (`\user{link};'). The available tags are depicted on figure~\ref{wp-driver-tags}.

\begin{figure}[htbp]
\begin{center}
  \begin{tabular}{lp{10cm}}
    \quad Tags & Operator Properties \\
    \hline
\texttt{commutative:} & specify a commutative symbol:
                        $x \odot y = y \odot x$ \\
\texttt{associative:} & specify an associative symbol:
                        $(x \odot y) \odot z = x \odot (y \odot z)$ \\
\texttt{ac:} & shortcut for \texttt{associative:} \texttt{commutative:} \\
\texttt{left:}  & balance the operator on left during export to solvers (requires the associative tag):
                  $x \odot y \odot z = (x \odot y) \odot z$ \\
\texttt{right:} & balance the operator on right during export to solvers (requires the associative tag):
                      $x \odot y \odot z = x \odot (y \odot z)$ \\
\texttt{absorbant:} \user{a-link}\texttt{:} & specify \user{a-link} as being the absorbant element of the symbol: \\
                     & $\user{a-link} \odot x = \user{a-link}$ \\
                     & $x \odot \user{a-link} = \user{a-link}$ \\
\texttt{neutral:} \user{e-link}\texttt{:} & specify \user{e-link} as being the neutral element of the symbol: \\
                     &  $\user{e-link} \odot x = x$ \\
                     &  $x \odot \user{e-link} = x$ \\
\texttt{invertible:} & specify simplification relying on the existence of an inverse: \\
                     &  $x \odot y = x \odot z \Longleftrightarrow y = z$ \\
                     &  $y \odot x = z \odot x \Longleftrightarrow y = z$ \\
\texttt{idempotent:} & specify an idempotent symbol: $x \odot x = x$ \\
\hline
\texttt{injective:} &  specify an injective function:\\
                      & $f(x_1,\ldots,x_n) = f(y_1,\ldots,y_n) \Longrightarrow \forall i \; x_i = y_i$ \\
\texttt{constructor:} & specify an injective function, that constructs different values
                        from any other constructor. Formally, whenever $f$ and $g$ are two
                        distinct constructors, they are both injective and:
                        $f(x_1,\ldots,x_n) \neq g(y_1,\ldots,y_m)$ forall $x_i$ and $y_j$. \\
\hline
\end{tabular}
\end{center}
\caption{Driver Property Tags}
\label{wp-driver-tags}
\end{figure}

\clearpage
\section{Plug-in Developer Interface}
\label{wp-api}

The \textsf{WP} plug-in has several entry points registered in the
\texttt{Dynamic}\footnote{See the \emph{plug-in development guide}}
module of \textsf{Frama-C}.

Those entry points are however deprecated.
Instead, a full featured \textsf{OCaml} API is now exported with the
\textsf{Wp} plug-in. As documented in the \textsf{Frama-C} user manual, simply add the directive \verb!PLUGIN_DEPENDENCIES+=Wp! to the Makefile of your plug-in.

The high-level API for generating and proving properties is exported
in module \textsf{Wp.API}. The logical interface, compilers, and memory models are also accessible. See the generated \textsf{HTML} documentation of the platform for details.

\section{Proof Obligation Reports}

The \textsf{WP} plug-in can export statistics on generated proof
obligations. These statistics are called \textit{WP reports} and are
distinct from those \textit{property reports} generated by the
\textsf{Report} plug-in. Actually, \textit{WP reports} are statistics
on proof obligations generated by \textsf{WP}, whereas
\textit{property reports} are consolidated status of properties,
generated by the \textsf{Frama-C} kernel from various analyzers.
We only discuss \textit{WP reports} in this section.

Reports are generated with the following command-line options:
\begin{description}
\item[\tt -wp-report <Rspec$_1$,...,Rspec$_n$>] specifies the list of 
  reports to export.
  Each value \texttt{Rspec$_i$} is a \textit{WP report} specification file 
  (described below).
\item[\tt -wp-report-basename <name>] set the basename for exported
  reports (described below).
\item[\tt -wp-report-json <file>.json] output the reports in JSON format.
  If the file already exists, it is used to stabilize the \verb+range+ of steps
  reports in all other reports (see below).
\end{description}

Reports are created from user defined wp-report specification files.
The general format of a wp-report file is as follows:

\begin{logs}
  <configuration section...>
  @HEAD
  <head contents...>
  @CHAPTER
  <per chapter contents...>
  @SECTION
  <per section contents of a chapter...>
  @TAIL
  <tail contents...>
  @END
\end{logs}

The configuration section consists of optional commands, one per line,
among:
\begin{description}
\item[\tt @CONSOLE] the report is printed on the standard output. \\
  Also prints all numbers right-aligned on 4 ASCII characters.
\item[\tt @FILE "<\textit{file}>"] the report is generated in file \textit{file}.
\item[\tt @SUFFIX "<\textit{ext}>"] the report is generated in file \textit{base.ext},\\
  where \textit{base} can be set with \texttt{-wp-report-basename} option.
\item[\tt @ZERO "<\textit{text}>"] text to be printed for $0$-numbers. Default is \verb+"-"+.

\item[\tt @GLOBAL\_SECTION "<\textit{text}>"] text to be printed for the chapter name about globals 
\item[\tt @AXIOMATIC\_SECTION "<\textit{text}>"] text to be printed for the chapter name about axiomatics 
\item[\tt @FUNCTION\_SECTION "<\textit{text}>"] text to be printed for the chapter name about functions

\item[\tt @AXIOMATIC\_PREFIX "<\textit{text}>"] text to be printed before axiomatic names. 
  Default is \verb+"Axiomatic"+ (with a trailing space).
\item[\tt @FUNCTION\_PREFIX "<\textit{text}>"] text to be printed before function names. Default is empty.
\item[\tt @GLOBAL\_PREFIX "<\textit{text}>"] text to be printed before global property names.
  Default is \verb+"(Global)"+ (with a trailing space).
\item[\tt @LEMMA\_PREFIX "<\textit{text}>"] text to be printed before lemma names. 
  Default is \verb+"Lemma"+ (with a trailing space).
\item[\tt @PROPERTY\_PREFIX "<\textit{text}>"] text to be printed before other property names. 
\end{description}

The generated report consists of several optional parts, corresponding
to Head, Chapter and Tail sections of the wp-report specification file.  
First, the head contents lines are produced. 
Then the chapters and their sections are produced. 
Finally, the Tail content lines are printed.

The different chapters are about globals, axiomatics and functions.
Outputs for these chapters can be specified using these directives: 
\begin{description}
\item[\tt @CHAPTER] <\textit{chapter header...>}
\item[\tt @GLOBAL] <\textit{global section contents...>}
\item[\tt @AXIOMATIC] <\textit{per axiomatic section contents...>}\\
For each axiomatic, a specific section is produced under the chapter about axiomatics.
\item[\tt @FUNCTION] <\textit{per function section contents...>}\\
For each function analyzed by \textsf{WP}, a specific section is produced under the chapter about functions.
\item[\tt @SECTION] <\textit{default section contents...>}
\item[\tt @PROPERTY] <\textit{per property contents...>}\\
For each property of a section, a specific textual content can be specified.
\end{description}

Textual contents use special formatters that will be replaced by
actual statistic values when the report is generated. There are
several categories of formatters (PO stands for \emph{Proof Obligations}):

\begin{center}
  \begin{tabular}{ll}
    \textbf{Formatters} & \textbf{Description} \\
    \hline\hline    
    \verb+&<+{\it col}\verb+>:+ & insert spaces up to column \textit{col} \\
    \verb+&&+ & prints a \verb+"&"+ \\
    \verb+%%+ & prints a \verb+"%"+ \\
    \hline
    \verb+%<+{\it stat}\verb+>+ & statistics for section \\
    \verb+%prop+ & percentage of proved properties in section \\
    \verb+%prop:total+ & number of covered properties \\
    \verb+%prop:valid+ & number of proved properties \\
    \verb+%prop:failed+ & number of remaining unproved properties \\
    \verb+%<+{\it prover}\verb+>+ & PO discharged by \textit{prover} \\
    \verb+%<+{\it prover}\verb+>:<+{\it stat}\verb+>+ & statistics for \textit{prover} in section \\
    \hline
  \end{tabular}
\end{center}

\begin{center}
  \begin{tabular}{ll}
    \hline
    \textbf{Provers} \\ 
    (\verb+<+{\it prover}\verb+>+) & A prover name (see \texttt{-wp-prover}) \\
    \hline
    \hline
    \textbf{Statistics} \\
    (\verb+<+{\it prover}\verb+>+) \\
    \verb+total+ & number of generated PO \\
    \verb+valid+ & number of discharged PO \\
    \verb+failed+ & number of non-discharged PO \\
    \verb+time+ & maximal time used by prover for one PO \\
    \verb+steps+ & maximal steps used by prover for one PO \\
    \verb+range+ & range of maximal steps used by prover (more stable)\\
    \verb+success+ & percentage of discharged PO \\
    \hline
  \end{tabular}
\end{center}

\textbf{Remarks:} \verb+&ergo+ is a shortcut for \verb+&alt-ergo+. Formatters
can be written \verb+"%.."+ or \verb+"%{..}"+. When \verb+range+ is used
instead of \verb+steps+, the maximal number $n$ of steps is printed as a range $a..b$ that
contains $n$.
When option \verb+-report-json+ is used, the previous rank $a$ and $b$ are kept when
available and still fits with the new maximal step number. Otherwise, $a$ and $b$ are re-adjusted
following an heurisitics designed to increase the stability for non-regression testing.

Textual contents can use naming formatters that will be replaced by
current names:
\begin{center}
  \begin{tabular}{ll}
   \textbf{Names} & \textbf{Description} \\
    \hline\hline    
    \verb+%chapter+ & current chapter name \\
    \verb+%section+ & current section name \\
    \verb+%global+ & current global name (under the chapter about globals)\\
    \verb+%axiomatic+ & current axiomatic name (under the chapter about axiomatics) \\
    \verb+%function+ & current function name (under the chapter about functions)\\
    \verb+%name+ & current name defined by the context:\\
                 & - property name inside \texttt{@PROPERTY} contents,\\
                 & - function name inside \texttt{@FUNCTION} contents,\\
                 & - axiomatic name inside \texttt{@AXIOMATIC} contents,\\
                 & - global name inside \texttt{@GLOBAL} contents,\\
                 & - section name inside \texttt{@SECTION} contents,\\
                 & - chapter name inside \texttt{@CHAPTER} contents.\\
    \hline
  \end{tabular}
\end{center}
\clearpage

%-----------------------------------------------------------------------------
\section{Plug-in Persistent Data}
\label{wp-persistent}

As a general observation, almost \emph{none} of the internal
\textsf{WP} data is kept in memory after each execution. Most of the
generated proof-obligation data is stored on disk before being sent to
provers, and they are stored in a temporary directory that is removed
upon \textsf{Frama-C} exit (see also \texttt{-wp-out} option).

The only information which is added to the \textsf{Frama-C} kernel
consists in a new status for those properties proved by \textsf{WP} plug-in with
their dependencies.

Thus, when combining \textsf{WP}
options with \texttt{-then}, \texttt{-save} and \texttt{-load}
options, the user should be aware of the following precisions:
\begin{description}
\item[\tt -wp, -wp-prop, -wp-fct, -wp-bhv.] These options make the
  \textsf{WP} plug-in generate proof-obligations for the selected
  properties. The values of theses options are never saved and they are
  cleared by \texttt{-then}. Hence, running \texttt{-wp-prop A}
  \texttt{-then} \texttt{-wp-fct F} does what you expect: 
  properties tagged by \texttt{A} are proved only once.
\item[\tt -wp-print, -wp-prover, -wp-gen, -wp-detect.] These options do not
  generate new proof-obligations, but run other actions on all
  previously generated ones. For the same reasons, they are not saved
  and cleared by \texttt{-then}.
\item[\tt -wp-xxx.] All other options are tunings that can be easily
  turned on and off or set to the desired value. 
  They are saved and kept across \texttt{-then} commands.
\end{description}

%-----------------------------------------------------------------------------

% vim: spell spelllang=en