Re: address of a statement in C

From: Dave Thompson (david.thompson1_at_worldnet.att.net)
Date: 11/08/04


Date: Mon, 08 Nov 2004 09:40:54 GMT

On 3 Nov 2004 10:52:39 -0800, candy_init@yahoo.com (candy) wrote:

> hi all,
>
> Is there is any way in the C language by which I can get the
>
> address of a statement? For eg,consider the following simple program:
>
> 1. #include<stdio.h>
> 2.
> 3. int main(void){
> 4. int variable;
> 5. return 0;
> 6. }
>
> Well is there is any way by which I can know the address of the
> statement which is in the line 4?
>
Formally line 4 is a declaration not a statement. And more imporant,
on typical contemporary machines, there is no executable code
generated specifically for it.

> Also,if I know the address of a statement then can I
>
> transfer the control to that statement by equating program
>
> counter equal to that address? Well,I can access as well as
>
> modify the program counter with the help of the
>
> setjmp(jmp_buf env) function.
>
>
You can't do any such thing portably with setjmp (and longmp); the
contents of jmp_buf are entirely implementation-dependent, often
opaque, and even compiler-version or target(-version) dependent.

C doesn't even require that an implementation have a program counter.
I don't see much likelihood of a return of the serial-memory effect of
the old drum machines, like that IIRC in The Story of Mel, but some
microarchitectures are explicit-next aka n+1-address and it might
conceivably make sense for a C implementation to target one of them at
least partially (e.g. for computational cores).

Even if you meant an actual statement like line 5, or a declaration
that in fact generates specific code (like an initialized automatic on
at least the vast majority of current systems), on a "normal" (general
purpose (pseudo)sequential) machine, there is no requirement that
there be a singular address; it is entirely permissible for code from
multiple statements (etc.) to be duplicated, interleaved and/or
reordered, as long as _externally_ visible effects (basically only I/O
and volatile accesses if supported and used) occur "as if" the code
had actually been executed in an order consistent with the abstract
semantics -- and even then it need not be _stored_ in order. And
modern optimizing compilers often do such reordering; they also break,
and combine, source statements (etc.) into "basic blocks" at different
boundaries for purposes of code generation, placement and alignment.

So in short, no.

In GCC as an extension you can set a (void) pointer to point to a
label, and goto that pointer. That pointer value is in effect _an_
address for the labelled statement, not necessarily the only one.
And valid only within the same function invocation (stack frame).

- David.Thompson1 at worldnet.att.net



Relevant Pages

  • Re: void pointers & void function pointers
    ... > void; ... try to coerce a pointer of one class to a pointer of the other, ... Machines that maintain "permission bits" on regions of memory ...
    (comp.lang.c)
  • Re: 32 or 64 bit processor info in C
    ... If you consider any particular kind of object (or pointer) to correspond to something you think makes something a "32 or 64 bit processor", then you can take its size in chars with sizeof and multiply by CHAR_BIT. ... The one programming problem that C certainly cannot handle is cleaning up the semantics of "32 or 64 bit processor", which has a number of meanings. ... The number of machines with word sizes such that they are not describable as 32-bit or 64-bit machines is very large. ...
    (comp.lang.c)
  • Re: Integers on 64-bit machines
    ... thought a bit about 64-bit machines and wanted to ask: ... pointers, e.g., pointer arithmetic), the main integer type should have ... It causes lots of portability bugs; ... M. Anton Ertl ...
    (comp.compilers)
  • Re: porting problems encountered
    ... We are adding 15 to myP, an integer, not p, the pointer. ... bit machines are fine with fetching 64 bit values from 32 bit bounded ... they like to fetch 64 bit values from addresses that end in 0 ... understanding THAT requires understanding what the hardware is doing. ...
    (comp.os.vms)