🚀 go-pugleaf

In article <964@caslon.cs.arizona.edu>, dave@cs.arizona.edu (Dave P.
Schaumann) writes:
|>In article <17114@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com
(Christopher R Volpe) writes:
|>|In article <955@caslon.cs.arizona.edu>, dave@cs.arizona.edu (Dave P.
|>|Schaumann) writes:
|>|||Oh really?  Seems to me that &foo.a.b.c.d[0] is a constant that can be
|>|||computed *at compile time*.  
|>|
|>|Oh really? What if the type of "foo.a.b.c.d" is "struct bar *" and you
|>|initialize it with:
|>|    foo.a.b.c.d = (struct bar *) malloc(15 * sizeof(struct bar));
|>|
|>|Then neither &foo.a.b.c.d[0] nor &foo.a.b.c.d[11] are compile time
|>|constants.                        
|>
|>I think you're wrong.  If the base address of foo is known at compile time,
|>then &foo.a.b.c.d[0] is simply a constant offset from this base address,
|>and this constant *must* calculatable at compile time for the compiler to
|>generate code to access these fields.  And even if the base address of foo is
|>unknown at compile time, the expression foo.a.b.c.d still represents a known
|>constant offset from an unknown base address.

I don't think so. If the base address of {foo} is known at compile time,
then the ADDRESS of {foo.a.b.c.d} is known at compile time. However,
{&foo.a.b.c.d[0]} is by definition the VALUE of {foo.a.b.c.d}, which is
the value returned by malloc, which is NOT known at compile time. Look again
at what that expression is computing. It's the address of the first element
of an array whose storage was allocated at run time. How can that be known
at compile time?

==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com