An Extension to Pointer Logic for Verification

Abstract

The safety of pointer programs is an important issue in high-assurance software design, and their verification remains a major challenge. Pointer Logic has been proposed to verify basic safety properties of pointer programs in our previous work, but still lacks support for a wide range of pointer programs. In this work, we present an extension to Pointer Logic by: 1) introducing modular reasoning to scale better on programs involving function calls; 2) allowing pointer arithmetic to take more advantage of pointers in programming. Moreover, to demonstrate that Pointer Logic is a useful approach to verification, we implement a tool - pice to automatically verify a range of non-trivial programs, including basic operations on singly-linked lists, trees, circular doubly-linked list, dynamic arrays etc.

Full text

Page 1

An Extension to Pointer Logic for Verification
Zhifang Wang Yiyun ChenZhenming Wang Wei WangBo Tian
Department of Computer Science and Technology, University of Science and Technology of China
Hefei, 230026, China
Suzhou Institute for Advanced Study, University of Science and Technology of China
Suzhou, 215123, China
{zfwang7, zmwang4, wqsh}@mail.ustc.edu.cn yiyun@ustc.edu.cn tianbo@ustc.edu
Abstract
The safety of pointer programs is an important issue in
high-assurance software design, and their verification re-
mains a major challenge. Pointer Logic has been proposed
to verify basic safety properties of pointer programs in our
previous work, but still lacks support for a wide range of
pointer programs. In this work, we present an extension
to Pointer Logic by: 1) introducing modular reasoning to
scale better on programs involving function calls; 2) allow-
ing pointer arithmetic to take more advantage of pointers in
programming. Moreover, to demonstrate that Pointer Logic
is a useful approach to verification, we implement a tool –
plcctoautomaticallyverifyarangeofnon-trivialprograms,
including basic operations on singly-linked lists, trees, cir-
cular doubly-linked list, dynamic arrays etc..
1. Introduction
Nowadays software is widely used in various areas, and
potential errors such as dangling dereferences and memory
leaks might lead to serious damages. As a result, high-
assurance software is highly desirable. On the other hand,
software verification promises to overcome the current soft-
ware crisis of bug-ridden software. Pointers (references) are
widely used in modern programming languages for its effi-
ciency and flexibility, but they are also the source of errors
because of aliasing.
In recent years, program verification through formal rea-
soning to predict the effect that a program produces when
run on a physical machine, has made great progress in soft-
ware engineering. PCC (Proof Carrying Code) [16] pio-
neered by Necula has given light into the verification para-
digm which can be applied in actual software development.
In order to utilize the PCC paradigm for verification, vari-
ous approaches e.g., [15, 1, 23, 22] are proposed. However,
many of these approaches based on formal reasoning need
a theory to describe the semantics of the programming lan-
guage, and introduce concepts such as heaps, stacks etc.
explicitly that are not part of the syntax. Although use-
ful in reasoning about program properties, they compli-
cate the reasoning significantly. On the contrary, Pointer
Logic explores the possibility to directly handle the pro-
gram safety properties of a given state through sets of ac-
cess paths (pointers) instead of introducing stacks or heaps
explicitly – the reasoning is all syntactic.
Pointer Logic has been reported on in two earlier works
[6, 7]. However, existing Pointer Logic rules for function
calls associate the entire heap with each invocation, and the
function body might be verified more than once, thus it is
difficult to scale the current approach to more programs. We
believethatmodulartreatmentoftheheapwillallowtheim-
plementation to scale better on larger pieces of code. More-
over, it lacks support for pointer arithmetic, which hinders
wide usage of Pointer Logic for program verification. In
this work, we take a leap forward in addressing the afore-
mentioned issues by introducing modular reasoning and ex-
tending Pointer Logic with pointer arithmetic. We consider
the case of a C-like imperative language–PointerC, which
includes pointer arithmetic but excludes the address-of op-
eration. Although in [6, 7] a previous version of plcc(v1.5)
was released, it can only verify several simple programs and
verification conditions generated need proving manually in
COQ [8]. Therefore, we redesigned plcc(Current version
is v2.0) to verify a range of pointer programs without any
help frominteractive theorem provers –it’sfullyautomated.
As long as the programs are annotated with loop invariants,
pre- and post-conditions, the annotations are then automati-
cally checked for validity by calculating the strongest post-
conditions according to Pointer Logic rules and verifying a
number of induced implications internally.
Our contributions can be summarized as follows:
1. We introduce modular reasoning in Pointer Logic by
splitting the program states via reachability of objects,

Page 2

which enables us to verify more programs involving
function calls and helps efficient implementation of
Pointer Logic rules;
2. We extend Pointer Logic with limited pointer arith-
metic to verify the properties such as absence of array-
out-of-bound errors, absence of null pointers involved
in pointer arithmetic etc., besides the common guaran-
tees of memory safety;
3. To demonstrate that Pointer Logic is a useful approach
to verification, we implemented plcc(v2.0) to auto-
matically verify a range of non-trivial pointer pro-
grams, including basic operations on lists, trees, circu-
lar doubly-linked lists, dynamic arrays. A bright fea-
ture of plcc(v2.0) is that it can generate human read-
able proof outlines when the verification is successful.
The rest of the paper is organized as follows. Section 2
defines the PointerC language. Section 3 introduces Pointer
Logic briefly. Section 4 presents the modular reasoning in
Pointer Logic. Section 5 extends Pointer Logic with pointer
arithmetic. Section 6 shows the experimental results. Sec-
tion 7 presents the related work and Section 8 concludes our
work.
2. The PointerC language
PointerC is a C-like imperative language which excludes
the address-of operation (&). The syntax is given in Figure
1. The notation z denotes a sequence of z’s. Note that we
Program
Struct. Decl.
Func. Decl.
Var. Decl.
Type
Statements
Statement
p
::=
::=
::=
::=
::=
::=
::=
|
|
|
|
::=
::=
|
::=
::=
stdec fndec
struct id {vdecl};
t id ( t id ){vdecl stms}
t id;
bool | int | struct id ∗ | t[]∗
stm stms | ?
l=e; | l=malloc(struct id);
l=calloc(t, e); | free(e);
if (be) {stms} else {stms}
while (be) {stms}
id(e); | l=id(e);
n | NULL | l | –e | e+e | ...
true | false | e==e | ...
be ∧ be | be ∨ be | ¬be
id | l->id | l(->id)e
0 | 1 | 2 | ...
stdec
fndec
vdecl
t
stms
stm
Expression
Bool Exp.
e
be
Left Val.
Number
(Note:l(->id)eis only allowed to appear in assertions)
l
n
Figure 1. Definition of the PointerC language.
extend the type with t[]∗ to support dynamic array decla-
rations and add a system call calloc. Currently we only al-
low pointer arithmetic on dynamic arrays. Every successful
call of calloc(t,n) will return a dynamic array of type t[]∗
with length n. Also malloc and free functions are defined
as system calls and meet the basic requirements of safe pro-
grams. For example, every call to malloc always success-
fully returns and the objects allocated are not overlapped in
the heap. The type system is deferred to [21].
3. The Pointer Logic
In this section, we briefly introduce Pointer Logic. The
details are deferred to [7]. The basic idea is to represent
memory states by means of sets of pointers. Every dynam-
ically allocated object is denoted by a valid pointer set π
in which the r-values of the pointers are the same while l-
values are distinct. A pointer is valid if and only if it points
to a dynamically allocated object. A set of π sets repre-
senting all the objects in the heap is denoted by Π. Be-
sides, there are two special sets: an N set for null pointer
set and a D set for dangling pointer set which are used for
the purpose of catching memory errors such as null pointer
dereferences and dangling pointer dereferences etc.. As the
pointers in the same π set, the pointers in N or D are also
with distinct l-values. Note the representation captures the
heap structure exactly, for every object is described by a set
π and the pointers in these sets maintain the relationships
between objects.
For example, in Figure 2, the representation of Π is
????
????
????
????
??
? ?
????
????
?
?
?
? ?
? ?
?
?
Figure 2. An example of Π, N, and D.
{{p,q},{p->next},{p->next->next,r}}, N is {r->next},
and D is {s} (The cross in s represents meaningless loca-
tions and “/\ ”means null ). In Π, q->next does not show
up in set {p->next} because q->next and p->next have the
same l-value. In Pointer Logic, {p,q} denotes object Oa,
{p->next} denotes object Ob, while {p->next->next,r} de-
notes object Oc. As a result, the Π, N, and D sets capture
the topological structure of the heap exactly, the informa-
tion of which is useful for program verification.
3.1. The assertion language
In this section, we define the assertion language used for
program annotation. The syntax is given in Figure 3. Not

Page 3

Assertion
A
::=
|
|
::=
::=
::=
::=
::=
::=
::=
be | (A) | A ∧ A | A ∨ A
A ⇒ A | id(l) | Ψ | ¬A
∃id : d.A | ∀id : d.A
N | e..e
Π | N | D | C
Π ∧ {ls} | {ls}
{ls}N
{ls}D
C ∧ <l,l,e> | <l,l,e>
ls,l | l
Domain
Pointer Set
Valid Ptr. Sets
Null Ptr. Set
Dangling Ptr. Set
Dynamic Arr. Sets
Lval Set
d
Ψ
Π
N
D
C
ls
Figure 3. The assertion language.
all the sentences derived by this grammar can be assertions
here: (i) Pointer sets can be operands of conjunction and
disjunction operators, but can not be operands of the nega-
tive operator; (ii) The l-value in a set must be pointers, and
an l-value with type int or bool should not appear in the
set. Here we add C to support pointer arithmetic reasoning
which will be discussed in section 5.
Since the assertion designed is to describe memory
states, the conjunction of pointers sets is different from that
in propositional logic. When an assertion contains pointer
sets, contraction (A ⇒ A ∧ A), weakening (A ∧ B ⇒ A)
and the distributive law ((A∧B)∧C ⇒ (A∧C)∧(B∧C))
are not sound.
The assertion language can be used to describe widely
used data structures such as singly-linked lists, circular
doubly-linked lists, trees etc.. For example, we may use
a recursive definition for singly-linked lists:
list(p) ? {p}N∨ ({p} ∧ list(p->next))
in which the node of the list is defined as:
struct List{ int data; struct List * next;}
The definition list(p) says that a list might be empty, or
mightconsistofaheadpointedtobypandasub-listpointed
to by p->next. Also we might use a descriptive definition:
list(p) ? ∃n:N.(∀k:0..n-1{p(->next)k})∧{p(->next)n}N
which means that a singly-linked list is comprised of n ele-
ments. When n = 0, it just denotes an empty list. The ad-
vantage of this definition is that we can obtain accurate alias
relationship because integer coefficients in symbolic access
paths denote positions in data structures. In our current im-
plementation, both representations are well supported.
4. Modular reasoning
In this section, we introduce the frame rule and the rule
for function call. Existing Pointer Logic rules (see [7]) for
function calls associate the entire heap with each invoca-
tion, and the function body might be verified more than
once. However, a program often accesses part of the heap
instead of the whole heap. When we annotate a function, its
precondition only describes part of the heap which may be
modified by the function body. Thus modular treatment of
heaps for function call is a necessity. Furthermore, modular
reasoning helps efficient implementation of Pointer Logic
rules.
4.1. Objects and reachability
To make the reasoning more uniform, we introduce ob-
jects and reachability in this section.
In Pointer Logic every dynamically allocated object O is
represented by a set of pointers pointing to O. Here we
extend the concept about objects by assuming that every
pointer in N or D points to different virtual objects. This
makes sense because the following rules hold in Pointer
Logic:
{p1,p2,...,pn}N= {p1}N∧ {p2}N∧ ... ∧ {pn}N(1)
{p1,p2,...,pn}D= {p1}D∧ {p2}D∧ ... ∧ {pn}D(2)
Thus we can imagine that they are pointing to some virtual
objects in the heap.
DEFINITION 4.1 (REACHABILITY) An object,
sented by a set S, either a π set, or {x}N, or {x}D, is
reachable from pointer p, if and only if there exists pointer
q ∈ S such that ∃r.r ∈ closure(q) ∧ prefix(p,r). The
relationship of reachability is denoted by Reach(p,S).
repre-
The two functions closure and prefix are defined in [7], in
which closure(p) returns all the pointers that are with the
same l-value as p, and prefix(p,r) decides whether pointer
p is a prefix of r. Based on definition 4.1, we can define a
function to describe objects reachable from a set of pointers.
Let S = {p1,...,pn} be a set of pointers, we define:
R(S) ??n
where Πpi? {π | π ∈ Π ∧ Reach(pi,π)}; Npi? {q | q ∈
N ∧ ∃r.r ∈ closure(q) ∧ prefix(pi,r)}; Dpi? {q | q ∈
D ∧ ∃r.r ∈ closure(q) ∧ prefix(pi,r)}.
4.2. Inference rules
i=1Πpi∧?n
i=1Npi∧?n
i=1Dpi
(3)
First, we concentrate on the assignment rules from [7].
Existing rules for a destructive update have to perform a
substitution operation on all the sets of Π, N and D. Now
that we have the R function, we only have to update part of

Page 4

sets. For an assignment p = q, let R({p,q}) = Π{p,q}∧
N{p,q}∧D{p,q}be the objects reachable from p and q, and
Ψleft = (Π − Π{p,q}) ∧ (N − N{p,q}) ∧ (D − D{p,q})
be the unreachable. Assume after assignment, R({p,q})
turns into R?({p,q}) which could be obtained through the
functions in [7]. Thus the rule for assignment would be:
{R({p,q}) ∧ Ψleft} p = q {R?({p,q}) ∧ Ψleft} (4)
In this way efficient implementation of the assignment rules
can be obtained because only the reachable part of the heap
is modified.
Similarly, the frame rule is as follows:
{R(S1)} Stms {R(S1)?}
{R(S1) ∧ R(S2)} Stms {R(S1)?∧ R(S2)}
(5)
where S1and S2are two sets of root pointer variables and
R(Si) = ΠSi∧ NSi∧ DSi(i = 1,2) satisfying S1∩ S2=
∅ ∧ ΠS1∩ ΠS2= ∅.
The rule for function call bears a similar form. We as-
sume the formal parameters of function f are x1,...,xn,
the actual parameters are y1,...,yn, and its precondition
and postcondition are fpreand fpostwhich are parameter-
ized by f’s formal parameters. Note that the reachable ob-
jects from the actual parameters of a function are possibly
influenced by the function body. As a result, we only have
to split the memory states to obtain the local heaps the func-
tions might update:
R({y1,...,yn}) ⇒ fpre[y1,...,yn/x1,...,xn]
{Π ∧ N ∧ D} f(y1,...,yn)
{fpost[y1,...,yn/x1,...,xn] ∧ Ψleft}
(6)
In rule (6), Ψleftis analogous to the one in rule (4) and
fpre[y1,...,yn/x1,...,xn] instantiates the formal para-
meters in function f, which indicates that the function has
a local view that only includes objects reachable from its
actual parameters – unreachable remain unchanged. Hence
when a function is called, it operates on part of the heap.
This rule resembles the frame rule in the sense that the ef-
fect of a function call on a larger heap can be obtained from
its effect on a subheap.
Due to space limitations, we omit the rule for ret =
f(y1,...,yn).
5. Pointer Logic with pointer arithmetic
The advantage of pointer arithmetic is its flexibility and
convenience for the programming, such as accessing array
elements using the pointer itself as a loop control variable.
Moreover, highly efficient assembly code can be obtained
by using pointer arithmetic. However, flexible pointer arith-
metic might bring array-out-of-bound error when derefer-
encingapointerpointingtosomeelementofanarray. There
are cases when null pointers or dangling pointers are in-
volved in pointer arithmetic, while it is difficult to detect via
type checking. The goal of extending Pointer Logic with
pointer arithmetic is to verify pointer program properties
related to the correct use of dynamically allocated mem-
ory such as absence of null pointers or dangling pointers in-
volved in pointer arithmetic, absence of array-out-of-bound
errors, besides the common guarantees of absence of null
dereferences, memoryleaksetc.. Here, westudythereason-
ing in Pointer Logic by allowing limited pointer arithmetic
as a probe.
Since Pointer Logic collects pointer information which
is about the pointers pointing to heap blocks, we only allow
pointer arithmetic on pointers pointing to one-dimensional
dynamic arrays which are allocated by calloc(T,n). Func-
tion calloc is defined as a system call where T is the type
of elements and n is the length of the array. An example of
using calloc and pointer arithmetic is shown in Figure 4.
T[] *q;
q=calloc(T,10);
T *p,*r;
p=q+5;r=p+3;
Figure 4. An example for pointer arithmetic.
In Pointer Logic, when p ?≡ q (we denote by ≡ syn-
tactic equivalence), we use a triple <p,q,offset> to denote
pointers pointing to a dynamic array, where p is the inner
pointer with type T*, q is the base pointer with type T[]*,
and offset indicates the position in the dynamic array, i.e.,
p==q+offset∗sizeof(T). In this case, the triple expresses
the fact that pointer p points to position offset in a dynamic
array q. When p ≡ q, the triple <p,q,offset> just means the
length of the dynamic array p is offset. Note that the triple
we define records the information about pointers. For ex-
ample, in Figure 4, after an assignment p=q+5, the triple for
p is <p,q,5>; after another assignment r=p+3 the triple for
p is the same, while the triple for r is <r,q,8>.
In order to simplify the reasoning, we require that all
pointers pointing to dynamic arrays be root variables, and
that the elements of a dynamic array be of a simple type
without pointer fields, otherwise the form of the pointer
won’t be uniform and therefore will greatly complicate the
reasoning. However, these constraints can be relieved by
introducing more general and uniform representations of
pointers and rewriting more universal Pointer Logic rules.
5.1. Axioms and inference rules
In this section, we introduce the axioms and rules involv-
ing pointer arithmetic. In accordance with the rules in [7],
we try to make the minimum changes by adding a new kind

Page 5

of set C (See Figure 3) which is made up of a set of triples
describing pointers pointing to dynamic arrays. When two
pointers point to non-dynamic-array structures, the rules are
the same as in [7] since the program won’t modify any el-
ements in C. As a result, the rules in [7] can be treated
as a special case when C is empty or C stays the same. In
essence, C is a loose form describing pointers – every base
pointer in C is valid, every inner pointer is either valid or
dangling, the state of which depends on the value offset. If
offset is within the scope of the corresponding array, then
the pointer is valid, else it is dangling. Hence triples clas-
sify themselves, and there is no need to classify the triples
in C into more sets just as Π,N and D sets do. Note that
inner pointers won’t point to elsewhere, i.e., they won’t ap-
pear in Π, N or D. However, the pointers with dynamic
array type must appear in Π, N or D, because a dynamic
array as a whole can be viewed as an object in the heap.
To ease notation in the extended rules, we introduce
some helper functions and shortcuts shown in Figure 5.
Notation x.eq defined in [7] returns the equivalent set
C\p
? {<p?,q??,e> | <p?,q?,e> ∈ C ∧ ∃q??.q??∈ q?.eq∧
(∀p??.p??∈ closure(p) ⇒ ¬prefix(p??,q??))}
C − p ? {<p?,q?,e> | <p?,q?,e> ∈ C ∧ p??∈ closure(p)}
C + <p,q,n>
C − {p1,...,pn}
p <: C
p <: R
R − p
R + p
p <: Π
?
p.eq ∈ Π
Π + p
?
Π ∪ {{p}}
base(p)
?
q where ∃e : <p,q,e> ∈ C
index(p)
?
e where ∃q : <p,q,e> ∈ C
Figure 5. Shortcuts and helper functions.
?
?
C ∪ {<p,q,n>}
(...(C − p1)··· − pn)
∃<p?,q?,e> ∈ C : (p?∈ p.eq ∨ q?∈ p.eq)
closure(p) ∩ R ?= ∅
{q | q ∈ R ∧ q ?∈ closure(p)}
R ∪ {p}
?
?
?
?
pointer x is in. C\p deals with substitutions for every base
pointer q?which is prefixed by an alias of p, with another
pointer q??. C − p just removes the triple describing pointer
p. p <: C means that p is either an inner pointer or a base
pointer. Meta variable R denotes a set of pointers.
Because of the constraints we mentioned above, the rules
are simpler than we may have thought. The most important
of all, all the rules in [7] can be reused. However, the intro-
duction of C requires more rules to deal with dynamic array
assignment. We only highlight the differences.
1) Pointer p and q are pointing to non-dynamic-array struc-
tures:
p ?<: C ∧ q ?<: C
{Π ∧ N ∧ D ∧ C} p =q {Π?∧ N?∧ D?∧ C}
(7)
In rule (7) the assignment has no effect on C and the
Π?∧N?∧D?in postcondition is obtained through the corre-
sponding rules {Π ∧ N ∧ D} p=q {Π?∧ N?∧ D?} in [7].
As a result, we inherit the rules from [7] with little mod-
ification, and most memory errors can be caught by using
the rules in [7]. In the following rules, we assume that
Π?∧ N?∧ D?be obtained this way.
2) Pointer p and q are of dynamic array type:
(p <: N ∨ p <: D) ∧ q <: Π ∧ q <: C
{Π ∧ N ∧ D ∧ C} p=q {Π?∧ N?∧ D?∧ C}
((p <: Π ∧ q <: Π ∧ q <: C)
∨(p <: Π ∧ p <: C ∧ q <: N)) ∧ no leak(p)
{Π ∧ N ∧ D ∧ C} p=q {Π?∧ N?∧ D?∧ C\p}
Rule (8) and (9) are analogous to rule (7) in that the mod-
ification of the Π, N, and D part is obtained through the
rules in [7]. The no leak function defined in [7] ensures no
memory leaks can occur.
(8)
(9)
3) Pointer q is of dynamic array type, and p is of its ele-
ments’ type:
p ?<: Π ∧ p <: C ∧ q <: Π ∧ q <: C
{Π ∧ N ∧ D ∧ C} p=q + e
{Π ∧ N ∧ D ∧ (C − p + <p,q,e>)}
(p <: N ∨ p <: D ∨ p <: Π ∧ p ?<: C) ∧ q <: Π∧
q <: C ∧ {Π ∧ N ∧ D} p=NULL {Π?∧ N?∧ D?}
{Π ∧ N ∧ D ∧ C} p=q + e
{Π?∧ N?− p ∧ D?∧ (C + <p,q,e>)}
The intermediate assertion Π?∧N?∧D?is obtained through
the corresponding rule in [7].
(10)
(11)
4) Pointer p and q are both of dynamic-array-element type
for assignment p=q+e:
p ?<: Π ∧ p <: C ∧ q <: C ∧ q ?<: Π
{Π ∧ N ∧ D ∧ C} p=q + e {Π ∧ N ∧ D∧
(C − p + <p,base(q),index(q) + e>)}
(p <: N ∨ p <: D ∨ p <: Π ∧ p ?<: C) ∧ q <: C∧
q ?<: Π ∧ {Π ∧ N ∧ D} p=NULL {Π?∧ N?∧ D?}
{Π ∧ N ∧ D ∧ C} p=q + e {Π?∧ N?− p ∧ D?∧
(C + <p,base(q),index(q) + e>)}
(12)
(13)
5) Pointer p is of dynamic-array-element type:
p <: C
{Π ∧ N ∧ D ∧ C} p=NULL {Π ∧ N + p ∧ D ∧ (C − p)}
(14)