Content deleted Content added
it wasn't, except maybe in their own little sub-field, but it's better to have no info than false info; see talk; there's a survey in the EL section for the FP CFA which should be enough for now |
m Dating maintenance tags: {{Pn}} {{Which}} {{Rewrite}} {{Dubious}} |
||
Line 1:
{{rewrite|date=July 2014}}
In [[computer science]], '''control flow analysis''' is a [[static code analysis]] technique for determining the [[control flow]] of a program. The control flow is expressed as a [[control flow graph]] (CFG). For both [[functional programming language]]s and [[object-oriented programming language]]s, the term CFA, and elaborations such as ''k''-CFA, refer to specific algorithms that compute control flow.{{dubious|date=July 2014}}
For many [[imperative programming language]]s, the control flow{{which|date=July 2014}} of a program is explicit in a program's source code.{{dubious|date=July 2014}} As a result, [[interprocedural analysis|interprocedural]] control-flow analysis implicitly usually refers to a [[static analysis]] technique for determining the receiver(s) of function or method calls in computer programs written in a [[higher-order programming language]].{{dubious|date=July 2014}} For example, in a programming language with [[higher-order functions]] like [[Scheme (programming language)|Scheme]], the target of a function call may not be explicit: in the isolated expression
<source lang="scheme">
(lambda (f) (f x))
Line 8:
it is unclear to which procedure <code>f</code> may refer. To determine the possible targets, a control-flow analysis must consider where this expression could be invoked, and what argument it may receive.
Techniques such as [[abstract interpretation]], [[constraint solving]] and [[type system]]s may be used to compute control-flow analysis{{which|date=July 2014}}.<ref>Flemming Nielson, Hanne Riis Nielson & Chris Hankin (1999). ''Principles of Program Analysis''. Springer.</ref>{{pn|date=July 2014}}
== See also ==
| |||