Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > stack & passing variables

Reply
Thread Tools

stack & passing variables

 
 
Mark
Guest
Posts: n/a
 
      10-17-2011
Hello,

Consider the following simple code.

#include <stdio.h>
static void p2(int *pp)
{
printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
}

static int p1(void)
{
int p=10;
printf("p1: p=%d @ %p\n", p, (void *)&p);
p2(&p);

return 0;
}

int main(void)
{
p1();

return 0;
}

Is it guaranteed that object 'p' defined in function p1 will have the same
value and will be at the same address location, when it is used from
function p2 ? I know that the C standard doesn't operate such terms as
stack or heap, but as far as I understand most of the time automatic
variables (automatic -- local?) will be placed on the stack, and my question
is - is it safe to pass parameters this way? (I do not intend to *store*
anything at the locations of these parameters, only pass information and use
it once).

Thanks in advance.

Mark


 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      10-17-2011
On 10/16/2011 10:22 PM, Mark wrote:
> Hello,
>
> Consider the following simple code.
>
> #include <stdio.h>
> static void p2(int *pp)
> {
> printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
> }
>
> static int p1(void)
> {
> int p=10;
> printf("p1: p=%d @ %p\n", p, (void *)&p);
> p2(&p);
>
> return 0;
> }
>
> int main(void)
> {
> p1();
>
> return 0;
> }
>
> Is it guaranteed that object 'p' defined in function p1 will have the same
> value and will be at the same address location, when it is used from
> function p2 ? I know that the C standard doesn't operate such terms as
> stack or heap,


You're right - the standard doesn't talk about these issues in terms of
the stack or the heap. That's an implementation detail. The key point
is, that no matter what method the the implementation uses to set aside
storage for 'p', that storage much remain accessible throughout the
lifetime of 'p'. The lifetime of the 'p' starts when the body of p1 is
entered. It does not end until after the the return statement at the end
of p1. The pointer value that is the result of the &p expression will
remain valid throughout that lifetime. Since the call to p2 starts and
finishes during the call to p1(), the object p is still alive throughout
that call, so the pointer remains valid, and can be used in the fashion
indicated.
--
James Kuyper
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-17-2011
"Mark" <(E-Mail Removed)> writes:

> Consider the following simple code.
>
> #include <stdio.h>
> static void p2(int *pp)
> {
> printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
> }
>
> static int p1(void)
> {
> int p=10;
> printf("p1: p=%d @ %p\n", p, (void *)&p);
> p2(&p);
>
> return 0;
> }
>
> int main(void)
> {
> p1();
>
> return 0;
> }
>
> Is it guaranteed that object 'p' defined in function p1 will have the same
> value and will be at the same address location, when it is used from
> function p2 ?


Just to add a bit more to what has been said... Section 6.2.4 paragraph
2 says (in part):

"An object exists, has a constant address, and retains its last-stored
value throughout its lifetime."

and you've already had an answer about the lifetime of 'p' which does
indeed span the whole execution of 'p2'.

<snip>
--
Ben.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      10-17-2011
On Sun, 16 Oct 2011 22:22:04 -0400, Mark wrote:

> static void p2(int *pp)
> {
> printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
> }
>
> static int p1(void)
> {
> int p=10;
> printf("p1: p=%d @ %p\n", p, (void *)&p);
> p2(&p);


> Is it guaranteed that object 'p' defined in function p1 will have the
> same value and will be at the same address location, when it is used
> from function p2 ?


pp will compare equal to &p, and the two will reference the same memory
location. However, the two aren't guaranteed to have the same
representation and aren't guaranteed to produce the same results when
printed with "%p"; there may be multiple ways to represent a given
pointer, and the implementation is free to convert between them.

> I know that the C standard doesn't operate such
> terms as stack or heap, but as far as I understand most of the time
> automatic variables (automatic -- local?) will be placed on the stack,
> and my question is - is it safe to pass parameters this way? (I do not
> intend to *store* anything at the locations of these parameters, only
> pass information and use it once).


Yes, it is safe. And common. Passing a pointer to a variable is the only
way to have the function modify the variable (C doesn't have Pascal's
"var" parameters). Also, passing a pointer is likely to be more efficient
if the object is large.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-17-2011
Nobody <(E-Mail Removed)> writes:
> On Sun, 16 Oct 2011 22:22:04 -0400, Mark wrote:
>
>> static void p2(int *pp)
>> {
>> printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
>> }
>>
>> static int p1(void)
>> {
>> int p=10;
>> printf("p1: p=%d @ %p\n", p, (void *)&p);
>> p2(&p);

>
>> Is it guaranteed that object 'p' defined in function p1 will have the
>> same value and will be at the same address location, when it is used
>> from function p2 ?

>
> pp will compare equal to &p, and the two will reference the same memory
> location. However, the two aren't guaranteed to have the same
> representation and aren't guaranteed to produce the same results when
> printed with "%p"; there may be multiple ways to represent a given
> pointer, and the implementation is free to convert between them.


True, but unlikely to be an issue in practice. An implementation would
probably have to deliberately go out of its way to use different
representations for the pointer in these two contexts.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      10-18-2011
On Oct 17, 3:22*am, "Mark" <(E-Mail Removed)> wrote:
> Hello,
>
> Consider the following simple code.
>
> #include <stdio.h>
> static void p2(int *pp)
> {
> * * printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
>
> }
>
> static int p1(void)
> {
> * * int p=10;
> * * printf("p1: p=%d @ %p\n", p, (void *)&p);
> * * p2(&p);
>
> * * return 0;
>
> }
>
> int main(void)
> {
> * * p1();
>
> * * return 0;
>
> }
>
> Is it guaranteed that object 'p' defined in function p1 will have the same
> value and will be at the same address location, when it is used from
> function p2 ? *I know that the C standard doesn't operate such terms as
> stack or heap,


but it does have such terms as "automatic" and "dynamic" storage
(assuming I spelt them right!)


but as far as I understand most of the time automatic
> variables (automatic -- local?) will be placed on the stack, and my question
> is - is it safe to pass parameters this way? (I do not intend to *store*
> anything at the locations of these parameters, only pass information and use
> it once).
>
> Thanks in advance.
>
> Mark


 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      10-21-2011
Hello,

Consider the following simple code.

#include <stdio.h>
static void p2(int *pp)
{
printf("%s: pp=%d @ %p\n", "p2", *pp, (void *)pp);
}

static int p1(void)
{
int p=10;
printf("p1: p=%d @ %p\n", p, (void *)&p);
p2(&p);

return 0;
}

int main(void)
{
p1();

return 0;
}

Is it guaranteed that object 'p' defined in function p1 will have the same
value and will be at the same address location, when it is used from
function p2 ? I know that the C standard doesn't operate such terms as
stack or heap, but as far as I understand most of the time automatic
variables (automatic -- local?) will be placed on the stack, and my question
is - is it safe to pass parameters this way? (I do not intend to *store*
anything at the locations of these parameters, only pass information and use
it once).

Thanks in advance.

Mark
------------------------------------------------------------------

OK, one can get one's own stacks or even a memory management subsystem in one's program in C to gain speed, because one knows how the program will consume memory than the OS subsystem that does not know.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-21-2011
88888 Dihedral <(E-Mail Removed)> writes:
> Hello,
>
> Consider the following simple code.
>

[30 lines deleted]
>
> Thanks in advance.
>
> Mark
> ------------------------------------------------------------------
>
> OK, one can get one's own stacks or even a memory management subsystem in one's program in C to gain speed, because one knows how the program will consume memory than the OS subsystem that does not know.


Most of your followup was an *unmarked* quotation of the entire parent
article. Quoted text is normally marked with a leading "> " on each
line; even the lousy Google Groups interface should do this for you.

And your answer doesn't seem to have anything to do with the question.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      10-21-2011
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>88888 Dihedral <(E-Mail Removed)> writes:
>> Hello,
>>
>> Consider the following simple code.
>>

>[30 lines deleted]
>>
>> Thanks in advance.
>>
>> Mark
>> ------------------------------------------------------------------
>>
>> OK, one can get one's own stacks or even a memory management subsystem

>in one's program in C to gain speed, because one knows how the program
>will consume memory than the OS subsystem that does not know.
>
>Most of your followup was an *unmarked* quotation of the entire parent
>article. Quoted text is normally marked with a leading "> " on each
>line; even the lousy Google Groups interface should do this for you.
>
>And your answer doesn't seem to have anything to do with the question.


Just like yours.

(And mine, too)

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.


CLC in a nutshell.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why does std::stack::pop() not throw an exception if the stack is empty? Debajit Adhikary C++ 36 02-10-2011 08:54 PM
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
stack frame size on linux/solaris of a running application stack Surinder Singh C Programming 1 12-20-2007 01:16 PM
Why stack overflow with such a small stack? Kenneth McDonald Ruby 7 09-01-2007 04:21 AM
"stack level too deep"... because Threads keep their "starting" stack Sam Roberts Ruby 1 02-11-2005 04:25 AM



Advertisments