Re: Invalid code transformations

The poster, Frank Byrum posted an example of a program in which
a dependence analyzer failed to recognize that a call to strcpy could
modify variables other than its formal parameters. Frank said that the
problem was that the programmer was taking advantage of the compiler's
characteristics to assign to variables not explicitly specified in the
function call. I, however, believe that the problem is in the semantic
model that Frank is postulating for C, rather than in the compiler.
Since a pointer can address any part of memory in C, and since C supports
pointer arithmetic, one must presume that a call to a function that writes
to memory using a pointer *may indeed* write to any location in memory.
This is simply a feature of the language's semantic definition.
A safe analysis of flow dependence must assume the worst, in the absence of
any assurances (read "assertions") to the contrary.
It is for this reason that researchers who have been writing papers
on dependence analysis in languages with heap allocation (check out the
Ruggieri/Murtaugh paper in the latest POPL or the Larus/Hilfinger paper in
the latest SIGPLAN) disallow pointer arithmetic in their model languages.
To summarize: all bets are off if you don't disallow pointer arithmetic,
or don't constrain it somehow!


--Phil
[From Phil Pfeiffer <pfeiffer@speedy.cs.wisc.edu>]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.