On Fri, 24 Jul 2009, Robert Seacord wrote:
> A PDF Download of this paper is available at:
>
> http://www.sei.cmu.edu/publications/documents/09.reports/09tn023.html
This model still seems extremely poorly defined. The only sensible way to
fix this is a careful definition of the AIR abstract machine and what the
possible effects of each operation are on that machine, bearing in mind
issues regarding how some transformations may be applied to only some uses
of a particular expression.
Obvious questions would include the result of converting an out-of-range
int to a narrower signed type, or to the same type - can this conversion
change the value? Can it result in a value that is out of range for the
new type? What are the results of bitwise operations on values outside
the range of their type? Suppose you convert an int whose AIR value is
outside the range of long long, to long long - what possible results may
this have? (Note that conversions to signed integer types have
implementation-defined aspects in ISO C.)
For each integer operation - including implicit conversions etc. - you
need to work out what the semantics are to be for all possible inputs in
the AIR abstract machine, whether in or out of range. ("Possible inputs"
might include the possibility of values in the abstract machine that are
differently interpreted for different operations.) You then need to
ensure that the optimizations you wish to permit can be proved to be valid
transformations given the definition of the abstract machine - bearing in
mind that a subexpression may be propagated to the various locations in
which it is used before an implementation carries out transformations on
larger expressions, hence the issues with values being differently
interpreted in different cases. The examples you give may be appropriate
for an ultra-simplistic model of source-to-source transformations; they
are of very little help for real transformations on internal
representation with a much more complicated relation to the source code.
If an operation that overflows has been carried out, may the AIR abstract
machine then trap at any future time (if the implementation has moved or
copied the relevant operation to that future time)? That would suggest
the abstract machine involves a one-way transition to a potentially
trapping state - but the semantics for operations on out-of-range values
need to be defined to say what happens in that state for as long as the
machine has not actually trapped.
--
Joseph S. Myers
[email protected]
