PLEASE HELP - Fundamental C language question

[cpptutor2000@yahoo.com]

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.

[Chad]

Re: PLEASE HELP - Fundamental C language question


cpptutor2000@ya hoo.com wrote:[color=blue]
> 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.[/color]

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]

Re: PLEASE HELP - Fundamental C language question

cpptutor2000@ya hoo.com said:
[color=blue]
> 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[/color]

More precisely, the array intArray is an automatic object.
[color=blue]
> and so destroyed
> when function returns, is it safe to say that at compile time it is
> not known what ip points to?[/color]

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]

Re: PLEASE HELP - Fundamental C language question

On 2005-10-30, Chad <cdalten@gmail. com> wrote:[color=blue]
>
> cpptutor2000@ya hoo.com wrote:[color=green]
>> 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.[/color]
>
> 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[/color]

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]

Re: PLEASE HELP - Fundamental C language question


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

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.