Home > Archive > C > October 2005 > PLEASE HELP - Fundamental C language question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
PLEASE HELP - Fundamental C language question
|
|
| cpptutor2000@yahoo.com 2005-10-29, 9:55 pm |
| 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.
| |
|
|
cpptutor2000@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
| |
| Richard Heathfield 2005-10-30, 3:55 am |
| cpptutor2000@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)
| |
| Jordan Abel 2005-10-30, 7:55 am |
| On 2005-10-30, Chad <cdalten@gmail.com> wrote:
>
> cpptutor2000@yahoo.com wrote:
>
> 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
| |
| Malcolm 2005-10-30, 6:56 pm |
|
<cpptutor2000@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.
|
|
|
|
|