By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,027 Members | 1,998 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,027 IT Pros & Developers. It's quick & easy.

PLEASE HELP - Fundamental C language question

P: n/a
Could some C guru please help me? Suppose I have a code snippet as:
int* doit(){
int intArray[25];
int *ip;
ip = intArray;
return ip;
}

Since the array intArray is allocated on the stack and so destroyed
when function returns, is it safe to say that at compile time it is
not known what ip points to?
Thanks in advance for your help.

Nov 15 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

cp**********@yahoo.com wrote:
Could some C guru please help me? Suppose I have a code snippet as:
int* doit(){
int intArray[25];
int *ip;
ip = intArray;
return ip;
}

Since the array intArray is allocated on the stack and so destroyed
when function returns, is it safe to say that at compile time it is
not known what ip points to?
Thanks in advance for your help.


If I remember right, it would also be safe to say that you won't know
what doit() points to. BTW, it is better to write int* doit() as int
*doit(void);

Chad

Nov 15 '05 #2

P: n/a
cp**********@yahoo.com said:
Could some C guru please help me? Suppose I have a code snippet as:
int* doit(){
int intArray[25];
int *ip;
ip = intArray;
return ip;
}

Since the array intArray is allocated on the stack
More precisely, the array intArray is an automatic object.
and so destroyed
when function returns, is it safe to say that at compile time it is
not known what ip points to?


At compile time, it doesn't point anywhere, because at compile time the
program isn't running!

When the function returns, the returned pointer is of no use, as you rightly
surmise, because the object to which it points (the first int in the array)
no longer exists. (Nor do the other ints in the array, of course!)

Solutions:

a) pass the address of the first array element as an argument;
b) create the space for the array dynamically;
c) make intArray static.

Of these, c) is the worst choice, in my opinion; b) is better, but you ought
to free the allocated memory when you're finished with it; a) is probably
the simplest choice.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Nov 15 '05 #3

P: n/a
On 2005-10-30, Chad <cd*****@gmail.com> wrote:

cp**********@yahoo.com wrote:
Could some C guru please help me? Suppose I have a code snippet
as:
int* doit(){
int intArray[25];
int *ip;
ip = intArray;
return ip;
}

Since the array intArray is allocated on the stack and so
destroyed when function returns, is it safe to say that at
compile time it is not known what ip points to?
Thanks in advance for your help.


If I remember right, it would also be safe to say that you won't
know what doit() points to. BTW, it is better to write int* doit()
as int *doit(void);

Chad


It doesn't matter when he's defining a function like that. int
*doit(void) is better when declaring a prototype because int *doit()
means not to check arguments at all
Nov 15 '05 #4

P: n/a

<cp**********@yahoo.com> wrote
Could some C guru please help me? Suppose I have a code snippet as:
int* doit(){
int intArray[25];
int *ip;
ip = intArray; /* at this point we can use ip eg *ip = 123 will set intArray[0] to 123 */ return ip;
}


intArray is an "automatic variable". Usually but not always this means it is
put on a stack. Some small embedded systems use a different system.

Yu cannot use the return address of this function at all. Probably if you do
you will corrupt the first variable of any subroutine called next, but you
could cause a crash or a system defined error, or anything ("undefined
behaviour". Even loading the return address into a variable

/* illegal */
int *ptr - doit();

can cause a crash. Some very advanced systems detect that the pointer is
pointing to memory the program doesn't own, and terminate with an error
message.
Nov 15 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.