Points-to Analysis

1
Points-to Analysis

• Jeff Foster, Manuel Fähndrich, Zhendong Su, Alex
  Aiken

2
Introduction

• Programs with pointers break program analysis
• b 3
• a b
• a 5
• Standard assumption
• a may be aliased to anything
• Can we do better?

3
Points-to Analysis (PTA)

• A form of alias analysis
• For every program variable x compute
• PTSet (x) locations to which x may point
• Useful/necessary for analyzing C
• All interesting C programs use pointers

4
Two Aliasing Questions

• May-alias
• might a and b be aliased?
• Must-alias
• are a and b always aliased at this point?

5
Styles of Analysis

• Flow-sensitive/-insensitive
• Respect/ignore ordering of assignments
• Context-sensitive/-insensitive
• Distinguish/conflate call sites
• We know a lot about
• flow-insensitive may-alias analysis

6
Andersens Analysis

• For assignment e1 e2
• PTSet (e2) ? PTSet (e1)

a b a c a d
7
Steensgaards Analysis

• For assignment e1 e2
• PTSet (e2) PTSet (e1)
• Note Actually use conditional unification

a b a c a d
8
Results

• Andersens analysis more precise that
  Steensgaards analysis SH97
• Flow-sensitive analyses dont scale ZRL98
• Andersens analysis scaleable to large programs
• Cycle elimination FFSA98
• Projection merging SFA00
• Important to distinguish fields others

9
Motivation for Polymorphism

• Monomorphic analysis conflates call sites

int id(int x) return x ...a id(b) c
id(d)...
10
Polymorphism

• Fresh copy of function at every call site
• Hard to implement correctly, efficiently

int id(int x) return x ...a id(b) c
id(d)...
11
More Results

• Hindley-Milner Polymorphism does not seem useful
  FFA00
• Monomorphic Andersens analysis good choice
• Other styles of polymorphism? FRD00
• Also Liblit

12
Issues

• PTA is a whole-program analysis
• Need models for library/app functions
• Little evidence PTA useful in practice
• Some evidence starting to emerge
• ...but, aliasing is a major issue in C

13
Type Qualifiers
Jeff Foster, Manuel Fähndrich, Alex Aiken
14
Introduction

• Goal Statically check programs for bugs
• Need information from programmer
• Many annotation languages exist
• few used in practice
• What specifications are programmers willing to
  write?

15
Specifications

• Should be
• Easy to write
• Minimize new notation
• Applicable to legacy programs
• Easy to maintain
• Useful
• Expressive enough

16
Proposal Type Qualifiers

• Programmers use type systems
• Lets expand type systems just a little
• Popular idea type qualifiers
• Annotate types to provide extra info
• const double pi 3.14159265

17
Humorous Interlude

• The primary purpose of the DATA statement is to
  give names to constants instead of referring to
  pi as 3.141592653589793 at every appearance, the
  variable PI can be given that value with a DATA
  statement and used instead of the longer form of
  the constant. This also simplifies modifying the
  program, should the value of pi change.
• -- FORTRAN manual for Xerox Computers

18
Example Qualifiers

• const ANSI C
• intptr C9X
• low/high security
• YY/YYYY/NONYEAR Y2K
• local/global Titanium (Liblit)
• kernelptr/userptr Linux kernel
• regionptr Custom allocation

19
Qualifiers and Subtyping

• Idea Qualifiers introduce subtyping
• Each qualifier comes with a partial order
• int lt const int
• char low lt char high
• local int lt global int
• Qualifiers otherwise uninterpreted
• Purely syntactic (operational) view

20
Qualified Type Systems

• Types annotated with sets of qualifiers
• r Q int Q (r -gt r)
• Add subtyping rules

Q1 lt Q2 r1 lt r1 r2 lt r2 Q1 (r1 -gt r1) lt Q2
(r2 -gt r2)
21
Annotations and Assertions

• Annotations introduce qualifiers
• (q e) (q e) s top-level qualifier is at least q
• x high read_secure_data(...)
• Assertions check for qualifiers
• e q e s top-level qualifier is at most q
• y nonconst x

22
Type Inference

• Qualifiers easy to infer
• Flow between annotations and assertions
• Standard atomic subtype inference (fast)
• Amenable to polymorphism

23
State Changes

• Standard types fixed throughout program
• Cant model some imperative conventions
• Solution flow-sensitive type qualifiers
• Qualifiers can change at any program point
• Judgments look like A - e t A
• Type inference still works

24
Example locked/unlocked

• ...
• lock(my_lock)
• ...
• if (err)
• unlock(my_lock)
• return
• ...
• unlock(my_lock)
• ...

state of my_lock changes lock/unlock not quite
lexically scoped
25
Example open/closed

• FILE safe_open(char x)
• ...
• if (result open(x, ...))
• ...
• ...
• foo safe_open(my_file)
• ...
• close(foo)

state of foo changes open/close not even in same
function
26
Current Work

• Implementing inference for this style of type
  qualifier
• Check some cases of locking
• Add some form of polymorphism
• Reduce unrealizable paths

27
Future Work

• Better solution for aliasing
• When x changes type, do its aliases change?
• Qualified types are abstraction of program state
• Check temporal predicates (e.g., this lock will
  eventually be released)

28
Opinion 1

• Programs assembled out of pieces
• C does not enforce abstractions
• You can make progress by checking these
  abstractions

29
Opinion 2

• Programmers dont want to write their program
  twice
• Complicated specifications are a difficult sell
• Except critical apps (time, money, safety)
• Specifications should be lightweight
• Tools need to be as automatic as possible