Related articles |
---|
Note on note on C as int. rep. chased@Eng.Sun.COM (1990-08-15) |
Newsgroups: | comp.compilers |
From: | chased@Eng.Sun.COM (David Chase) |
Keywords: | C |
Organization: | Compilers Central |
Date: | Wed, 15 Aug 90 00:48:32 GMT |
>> [The ANSI standard says that &b[0] - &a[0] is invalid unless a and b
point into the same array, and that &a[-100] is OK only if the result
of the subscripting is an element of the array that a points to. But I
can believe that in many cases hacks like that are necessary to trick a
C compiler into doing what you want it to. -John]
You missed my point, I'm afraid. True, the ANSI standard says that
programmers cannot do that. However, I don't believe it says anything about
doing the equivalent transformations in an optimizing compiler. After the
optimizer has run, there is no guarantee that the pointers as written in C
can be found at all in the transformed program. Thus, given something like:
char * a;
for (i = 100; i != n; i++)
{
a[i - 100] = g(a[i - 100], i);
}
i = 0; /* kill it here for sake of example. */
the addressing is legal C, but the compiler might choose to generate (on
friendly architectures) something equivalent to &(a[-100]) in a temporary,
and discard the pointer to the start of "a" completely. Most times, that's
exactly the sort of thing people want an optimizing compiler to do (or
worse).
Even in the case of legal C transformations, requiring a collector to honor
any bit-pattern addressing the interior of an object as a pointer to the
object tends to both slow down (conservative) collection and increase the
chance of leaking (more sad experience from Modula-3 implementation, I'm
afraid).
David Chase
Sun Microsystems
[I misunderstood your original comment to refer to the generated C source.
There's no question that a C compiler is permitted to produce any object code
it wants that produces the correct results. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.