Re: Pointers in C

In article <2109@hubcap.UUCP> mrspock@hubcap.clemson.edu (Steve Benz) writes:
[discussion of binding of pointers to arrays/heap]
|Nevertheless, I can think of a rather large set of programs that
|aren't "valid K&R C programs": All those programs that use varargs.
|(At least by the definitions of varargs that I've seen.)


Yes, it is hard to make any usefull assumptions about a pointer being
used for varargs processing, or for wandering through a
core/executable file in a debugger (the other "fun" example I run
into often).


|> Also, on page 90 of K&R (version 1):
|> "You should also note the implications in the declaration that a pointer is
|> constrained to point to a particular kind of object."
|
|I think a C compiler would be very hard pressed to guarantee this sort
|of thing, with the cast operation lurking about. The only way to absolutely
|guarantee this is to do some unpleasantly complicated typechecking on
|every object in memory.


    In some sense, that's what an optimizing compiler tends to have to
do. In tightly-typed languages, there's more information about the
use of a pointer (and syntactic sugar), but one can extract the
required information from C in many of the common cases, based on
the **particular** optimization being applied.




Let's look at the example that started this discussion thread: a
pointer in a copy routine which, because it can point anywhere, is
proposed to invalidate my register history... (I'm assuming that the
optimizatio in question is fetch minimization).


    If the pointer is kept "within bounds" by the copy routine, then
we can assume that passing the pointer to the routine has exactly
the same effect as a local assignment through the pointer.


    If the pointer is not being kept within bounds, both the
non-optimized copy code and the optimized calling code fails.


    But it fails in a manner which does not involve the optimization!
If a function scribbles on memory, and I'm trying to do
fetch-minimization from memory, it doesn't matter if the fetch
minimization is rendered incorrect, because the fetch **itself** has
been rendered incorrect by the scribbler.


    You can apply this same kind of argument to a number of common
cases of optimization in the presence of errors, to discover which
optimizations are independent of/orthogonal to the error... And
apply more optimizations than expected on first glance. (In
a real sense, you're doing complicated mental typechecking on the
operations when you write the optimizer).


    In my global pessimizer, I assume all registers and all stack
entries are invalid at all times, and so generate code which
depends only on read-only data in the linkage segment and random
numbers in the heap.


--dave (whats a correctness?) c-b




--
  David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
  Geac Computers Ltd., | Computer science loses its
  350 Steelcase Road, | memory, if not its mind,
  Markham, Ontario. | every six months.
--

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