stack address is different when parameter is passed to function?

[ypjofficial]

Hello All,

since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used
for the variables inside the different functions are not.
below is my code
//program start
void fun1()
{int i;
cout<<&i;
}

void fun2()
{
int i;
cout<<&i;
}
int main()
{
fun1();
fun2();
}
//program end

Both gave the same output(address of local variable i) since the same
stack space is used.
//output is
0x0012FF24 //output from fun1
0x0012FF24 //output from fun2

But i get the different results when I make following chang in one of
the function.
void fun1(int i)
{
cout<<&i;
}

and inside main i call it as fun1(4)
but now the output is different.
//output is
0x0012FF2C //output from fun1
0x0012FF24 //output from fun2

So far I was thinking that since the function parameters are also
passed onto the stack, I should get the same output(same address for
both the local version of i).
I am using MSVC6.0

what could be the reason for this different output?

Thanks and Regards,
Yogesh Joshi

[Heinz Ozwirk]

<yp*********@indiatimes.comschrieb im Newsbeitrag
news:11**********************@s13g2000cwa.googlegr oups.com...

Hello All,

since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used
for the variables inside the different functions are not.
below is my code
//program start
void fun1()
{int i;
cout<<&i;
}

void fun2()
{
int i;
cout<<&i;
}
int main()
{
fun1();
fun2();
}
//program end

Both gave the same output(address of local variable i) since the same
stack space is used.
//output is
0x0012FF24 //output from fun1
0x0012FF24 //output from fun2

But i get the different results when I make following chang in one of
the function.
void fun1(int i)
{
cout<<&i;
}

and inside main i call it as fun1(4)
but now the output is different.
//output is
0x0012FF2C //output from fun1
0x0012FF24 //output from fun2

So far I was thinking that since the function parameters are also
passed onto the stack, I should get the same output(same address for
both the local version of i).

1. Just because parameters are also passed on the stack, you should expect
different addresses of local variables.

2. Even in your first case, the compiler would be free to put those local
variables at different places in memory.

3. The compiler is not required to use a stack for parameters, local
variables or anything else.

4. IIRC, the only stack required by the standard is the type std::stack.

(The standard mentions "stack unwinding" at some places, but it is
implementation defined, how local variables and parameters are organized.)

Regards
Heinz

[ypjofficial]

Hi Heinz,
Thanks for the quick reply.
But still i am not fully convinced.

1. Just because parameters are also passed on the stack, you should expect
different addresses of local variables.

But there is only one entry point for the stack and i.e at the top of
it.So where other than the top these local variables will get stored?

2. Even in your first case, the compiler would be free to put those local
variables at different places in memory.

Where in the memory other than stack? As local variables (auto)are
always pushed on the stack and there is single stack shared by all the
functions from a same program.

3. The compiler is not required to use a stack for parameters, local
variables or anything else.

Then what about the calling conventions.?They always specify the
pushing of parameters onto the stack. In case of C the default calling
convention is cdecl which pushes the parameters from right to left and
since in this case there is only one parameters to be passed onto the
stack,the stack address should be the same.
Thanks and Regards,
Yogesh Joshi

[Heinz Ozwirk]

<yp*********@indiatimes.comschrieb im Newsbeitrag
news:11**********************@p79g2000cwp.googlegr oups.com...

Hi Heinz,
Thanks for the quick reply.
But still i am not fully convinced.

>1. Just because parameters are also passed on the stack, you should
expect
different addresses of local variables.

But there is only one entry point for the stack and i.e at the top of
it.So where other than the top these local variables will get stored?

The only fixed address of a stack is its bottom. During execution of a
program data are pushed onto the stack or popped off it and the the address
of top of the stack varies.

>2. Even in your first case, the compiler would be free to put those local
variables at different places in memory.

Where in the memory other than stack? As local variables (auto)are
always pushed on the stack and there is single stack shared by all the
functions from a same program.

There are several possible solutions. I know of one that allocates blocks of
memory for all local variables of a function and manages these blocks in a
linked list.

>3. The compiler is not required to use a stack for parameters, local
variables or anything else.

Then what about the calling conventions.?They always specify the
pushing of parameters onto the stack. In case of C the default calling
convention is cdecl which pushes the parameters from right to left and
since in this case there is only one parameters to be passed onto the
stack,the stack address should be the same.

This group is dedicated to C++, not C. So whatever C does (or people thing,
C does) is of little concern. Also, cdecl is not part of the C++ standard
(and neither part of C, IIRC). C calling conventions only specify two items.
The caller is responsible for removing any parameters from whatever memory
has been used to pass them to the called function and all parameters (except
those declared as register parameters) must be stored in a contignous block
of memory with the first parameter at a smaller address than the following
ones. These conventions are required to implement variadic functions in a
predictable manner, but it isn't the only way to do so. Using a stack is a
convenient method to do so, but it isn't the only one.

Heinz

[Bo Persson]

<yp*********@indiatimes.comskrev i meddelandet
news:11**********************@p79g2000cwp.googlegr oups.com...

Hi Heinz,
Thanks for the quick reply.
But still i am not fully convinced.

>1. Just because parameters are also passed on the stack, you should
expect
different addresses of local variables.

But there is only one entry point for the stack and i.e at the top
of
it.So where other than the top these local variables will get
stored?

Wherever the compiler finds a good place. The standard doesn't place
any restrictions on this.

Especially, there are machines that doesn't have a hardware stack. It
can work anyway!

>

>2. Even in your first case, the compiler would be free to put those
local
variables at different places in memory.

Where in the memory other than stack? As local variables (auto)are
always pushed on the stack and there is single stack shared by all
the
functions from a same program.

That is your assumptions, perhaps based on how your compiler does it.
The language standards doesn't say how parameters are passed.

>

>3. The compiler is not required to use a stack for parameters,
local
variables or anything else.

Then what about the calling conventions.?They always specify the
pushing of parameters onto the stack. In case of C the default
calling
convention is cdecl which pushes the parameters from right to left
and
since in this case there is only one parameters to be passed onto
the
stack,the stack address should be the same.

Calling conventions are specific to each compiler (or possibly to the
OS). The C++ standard doesn't mention 'cdecl' at all.

Pushing parameters from right to left, is a common convention om
machines that have a stack, and you need to support a variable number
of parameters.

If you have just a few parameters, and the number is known, it is
equally common to pass the parameters in registers. (Unless someone
interferes with this, by taking the address of the parameter. In that
case it has to be stored in memory).
Bo Persson

[Kaz Kylheku]

yp*********@indiatimes.com wrote:

Hello All,

since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used

You're stretching the meaning of R&D beyond its usual elasticity.

[Markus Schoder]

yp*********@indiatimes.com wrote:

Hello All,

since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used
for the variables inside the different functions are not.
below is my code
//program start
void fun1()
{int i;
cout<<&i;
}

void fun2()
{
int i;
cout<<&i;
}
int main()
{
fun1();
fun2();
}
//program end

Both gave the same output(address of local variable i) since the same
stack space is used.
//output is
0x0012FF24 //output from fun1
0x0012FF24 //output from fun2

But i get the different results when I make following chang in one of
the function.
void fun1(int i)
{
cout<<&i;
}

and inside main i call it as fun1(4)
but now the output is different.
//output is
0x0012FF2C //output from fun1
0x0012FF24 //output from fun2

So far I was thinking that since the function parameters are also
passed onto the stack, I should get the same output(same address for
both the local version of i).
I am using MSVC6.0

what could be the reason for this different output?

As has been pointed this is all implementation dependent but what is likely
going is that the functions save some registers on the stack. Local
variables will likely be allocated on top of this save area whereas
parameters are probably located below the register save area.

[Thomas J. Gritzan]

yp*********@indiatimes.com schrieb:

Hello All,

since the programs' stack is shared among all the function inside the
program,

[...]

As the others have mentioned:

This is completly off topic. There is no stack in the C++ language
(well, there is std::stack)

You could:
- Use your debugger/disassembler and look at the maschine code.
- Ask in a platform or compiler specific newsgroup.

But i get the different results when I make following chang in one of
the function.
void fun1(int i)
{
cout<<&i;
}

and inside main i call it as fun1(4)
but now the output is different.
//output is
0x0012FF2C //output from fun1
0x0012FF24 //output from fun2

So far I was thinking that since the function parameters are also
passed onto the stack, I should get the same output(same address for
both the local version of i).

On my platform, the usual order is:
Put parameters on the stack,
Call the function (and put the return address on the stack),
Then reserve space for local variables.

I am using MSVC6.0

Very old compiler. Why don't you use a newer version?

--
Thomas

[ypjofficial]

Kaz Kylheku wrote:

yp*********@indiatimes.com wrote:

Hello All,

since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used

You're stretching the meaning of R&D beyond its usual elasticity.

Sorry..the exact word should be experimentation than the R&D

[Kaz Kylheku]

yp*********@indiatimes.com wrote:

Kaz Kylheku wrote:

yp*********@indiatimes.com wrote:

Hello All,
>
since the programs' stack is shared among all the function inside the
program,
I was just doing some R&D to see whether the same stack space is used

You're stretching the meaning of R&D beyond its usual elasticity.

Sorry..the exact word should be experimentation than the R&D

So then you're stretching "experimentation".

The stack layout used by the Microsoft compiler on x86 targets isn't
some natural phenomenon that requires empirical investigation. It's not
a trade secret either.

You're applying a completely stupid approach to learn about a run-time
architecture which people invented and which is described in documents.

Why don't you go to "msdn.microsoft.com", click on "Library", and then
search for a few keywords?

In a few clicks, I'm able to find documentation on stack frame layouts
not only for x86, but also for their embedded targets like ARM, MIPS,
SH. Tons of documentation, straight from Microsoft.

DOH!

[yogpjosh]

You're applying a completely stupid approach to learn about a run-time
architecture which people invented and which is described in documents.

Thanks..I take it as a compliment..as I thinks such stupid things
certainly makes the learning process interesting..