@@ -10,7 +10,7 @@ CBMC uses
10
10
[ assertions] ( http://en.wikipedia.org/wiki/Assertion_(computing) ) to
11
11
specify program properties. Assertions are properties of the state of
12
12
the program when the program reaches a particular program location.
13
- Assertions are often written by the programmer by means of the ` assert `
13
+ Assertions are often written by the programmer using the ` assert `
14
14
macro.
15
15
16
16
In addition to the assertions written by the programmer, assertions for
@@ -34,7 +34,7 @@ the following properties:
34
34
- ** Pointer safety.** Search for ` NULL ` -pointer dereferences or
35
35
dereferences of other invalid pointers.
36
36
37
- - ** Memory leaks.** Check whether the program constructs dyanamically
37
+ - ** Memory leaks.** Check whether the program constructs dynamically
38
38
allocated data structures that are subsequently inaccessible.
39
39
40
40
- ** Division by zero.** Check whether there is a division by zero in
@@ -48,7 +48,7 @@ the following properties:
48
48
49
49
- ** Undefined shifts.** Check for shifts with excessive distance.
50
50
51
- We refrain from explaining the properties above in detail. Most of them
51
+ We won't explain the properties in detail. Most of them
52
52
relate to behaviors that are left undefined by the respective language
53
53
semantics. For a discussion on why these behaviors are usually very
54
54
undesirable, read [ this] ( http://blog.regehr.org/archives/213 ) blog post
@@ -57,7 +57,7 @@ by John Regehr.
57
57
All the properties described above are * reachability* properties. They
58
58
are always of the form
59
59
60
- "* Is there a path through the program such that property ... is
60
+ "* Is there a path through the program such that some property is
61
61
violated?* "
62
62
63
63
The counterexamples to such properties are always program paths. Users
@@ -101,8 +101,7 @@ resulting goto-binary with pointer checks.
101
101
goto-cc expr.c -o in.gb goto-instrument in.gb out.gb --pointer-check
102
102
```
103
103
104
- We can now get a list of the assertions that have been generated as
105
- follows:
104
+ We can now get a list of the assertions that have been generated:
106
105
107
106
```
108
107
goto-instrument out.gb --show-properties
@@ -115,20 +114,20 @@ trace for the NULL-pointer dereference:
115
114
cbmc out.gb
116
115
```
117
116
118
- The goto-instrument program supports the following checks:
119
-
120
- Flag | Check
121
- -----------------------------|----------------------------------------------
122
- `--no-assertions` | ignore user assertions
123
- `--bounds-check` | add array bounds checks
124
- `--div-by-zero-check` | add division by zero checks
125
- `--pointer-check` | add pointer checks
126
- `--signed-overflow-check` | add arithmetic over- and underflow checks
127
- `--unsigned-overflow-check` | add arithmetic over- and underflow checks
128
- `--undefined-shift-check` | add range checks for shift distances
129
- `--nan-check` | add floating-point NaN checks
130
- `--uninitialized-check` | add checks for uninitialized locals (experimental)
131
- `--error-label label` | check that given label is unreachable
117
+ The goto-instrument program supports these checks:
118
+
119
+ | Flag | Check |
120
+ | ------------------------------ |------------------------------------------------------|
121
+ | `--no-assertions` | ignore user assertions |
122
+ | `--bounds-check` | add array bounds checks |
123
+ | `--div-by-zero-check` | add division by zero checks |
124
+ | `--pointer-check` | add pointer checks |
125
+ | `--signed-overflow-check` | add arithmetic over- and underflow checks |
126
+ | `--unsigned-overflow-check` | add arithmetic over- and underflow checks |
127
+ | `--undefined-shift-check` | add range checks for shift distances |
128
+ | `--nan-check` | add floating-point NaN checks |
129
+ | `--uninitialized-check` | add checks for uninitialized locals (experimental) |
130
+ | `--error-label label` | check that given label is unreachable |
132
131
133
132
#### Generating function bodies
134
133
@@ -145,16 +144,15 @@ function with an existing definition, the `--remove-function-body` option can be
145
144
used to remove the body of the function prior to generating a new one.
146
145
147
146
The shape of the stub itself can be chosen with the
148
- `--generate-function-body-options` parameter, which can take the following
149
- values:
147
+ `--generate-function-body-options` parameter, which can take these values:
150
148
151
- Option | Result
152
- -----------------------------|-------------------------------------------------------------
153
- `nondet-return` | Do nothing and return a nondet result (this is the default)
154
- `assert-false` | Make the body contain an assert(false)
155
- `assume-false` | Make the body contain an assume(false)
156
- `assert-false-assume-false` | Combines assert-false and assume-false
157
- `havoc` | Set the contents of parameters and globals to nondet
149
+ | Option | Result |
150
+ | -----------------------------|-------------------------------------------------------------|
151
+ | `nondet-return` | Do nothing and return a nondet result (this is the default) |
152
+ | `assert-false` | Make the body contain an assert(false) |
153
+ | `assume-false` | Make the body contain an assume(false) |
154
+ | `assert-false-assume-false` | Combines assert-false and assume-false |
155
+ | `havoc` | Set the contents of parameters and globals to nondet |
158
156
159
157
The various combinations of assert-false and assume-false can be used to
160
158
indicate that functions shouldn't be called, that they will never return or
@@ -192,7 +190,7 @@ int main(void)
192
190
```
193
191
194
192
Now, we can compile the program and detect that the error functions are indeed
195
- called by invoking these commands
193
+ called by invoking these commands:
196
194
197
195
```
198
196
goto-cc error_example.c -o error_example.goto
@@ -217,7 +215,7 @@ Which gets us the output
217
215
> ** 2 of 2 failed (2 iterations)
218
216
> VERIFICATION FAILED
219
217
220
- As opposed to the verification success we would have gotten without the
218
+ As opposed to the verification success we would have seen without the
221
219
instrumentation step.
222
220
223
221
The havoc option takes further parameters ` globals ` and ` params ` with this
0 commit comments