[comp.std.c] Can the address of a variable change during a function?

pardo@june.cs.washington.edu (David Keppel) (11/20/88)

Consider the following bit of C:

	    int
	zorch()
	{
	    int i, j;

	    j = 0;
	    bork (&i);
	    while (--i)
		j += i;
	    splat (&i, &j);
	    j += i;
	    return (j);
	}

Most current implementations will assign a location to each of i and
j at function declaration elaboration (e.g., when the function is
entered).  I can imagine, however implementations in which the address
of a variable is not constant throughout the function (see below).  In
this case, "bork" could squirrel away the pointer to 'i', and "splat"
could, say, read whatever is at the end of that 'squirreled away'
pointer.  In this case, the behavior of the program will be *very*
different than if the variables had been declared with

	    auto int i;
	    int j;

In which case the address of 'i' passed to bork() and splat() is (I
think) guaranteed to be the same.  I believe that the compiler is free
to implement the first bit of code as something like:

	; i => r2
	; j => r3


		clear	r3		; j <- 0
		move	r2,-(sp)	; give i an address
		move	sp,r0		; pass address of i
		call	bork

		move	(sp),r2		; unspill i
	L0:
		dec	r2		; --i
		br.leq	L1
		add	r2,r3,r3	; j += i
		branch	L0

	L1:
		move	r3,(sp)		; give j i's old address
		move	sp,r0		; pass address of j
		move	r2,-(sp)	; give i a new address
		move	sp,r1		; pass address of i
		call	splat

		add	(sp),-4(sp),r0
		sub	#8,sp,sp	; patch up sp
		return

I also belive that 'auto' has been removed from dpANS C.
Summarizing, the question is: "can a local parameter have several
addresses during one invocation of the function that it is declared
in?"  All help is appreciated.

	;-D on  ( Who would have thunk it... )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo

gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/20/88)

In article <6472@june.cs.washington.edu> pardo@cs.washington.edu (David Keppel) writes:
>I can imagine, however implementations in which the address
>of a variable is not constant throughout the function (see below).

The cases where this would be permissible are so rare as to make it
practically certain no compiler implementor would bother to do so.

You may safely write your code as though storage for a variable does
not move during its lifetime (except through an explicit realloc()).
Automatic variables do go out of scope upon exit from the block that
defines them, but they don't move around within the duration of the
block.

>In this case, the behavior of the program will be *very*
>different than if the variables had been declared with
>	    auto int i;
>	    int j;

No, the "auto" was implicit in the previous example.  In fact there
is no real use for an explicit "auto" keyword in C.

>I also belive that 'auto' has been removed from dpANS C.

No, it's listed as a storage class specifier in section 3.5.1.
Where do you get these strange beliefs?

jbuck@epimass.EPI.COM (Joe Buck) (11/22/88)

In article <8938@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>In this case, the behavior of the program will be *very*
>>different than if the variables had been declared with
>>	    auto int i;
>>	    int j;
>
>No, the "auto" was implicit in the previous example.  In fact there
>is no real use for an explicit "auto" keyword in C.

Well, I have found one use: bringing code up under buggy C compilers.
Some earlier versions of the Masscomp C compiler choke and die when
handed large programs with lots of "register" variables.  I almost
always got them to come up by specifying

	-Dregister=auto

Some people attempt

	-Dregister=

in such cases, but this often leads to invalid C.

-- 
- Joe Buck
	jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck,
	or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites