why the value is still available

[xdevel]

Hi,
in a function if I have

int * retArray()
{
int a[3] = {102,222,355};

printf("%p ", a);

return a;
}

and then in main()

int *p = retArray();
p++;
printf(" \n%p\n %d", p, *p);

the compiler warning me: ../c_test.c: In function 'retArray':
.../c_test.c:24: warning: function returns address of local variable
and for this why the array variables values are still there ?

I've studied that when the function end the local variables loosing
their values as they
are distroyed and so If I want that they are not destroyed I should use
the static word before them...

[Nils O. Selåsdal]

xdevel wrote:

Hi,
in a function if I have

int * retArray()
{
int a[3] = {102,222,355};

printf("%p ", a);

return a;
}

and then in main()

int *p = retArray();
p++;
printf(" \n%p\n %d", p, *p);

the compiler warning me: ../c_test.c: In function 'retArray':
../c_test.c:24: warning: function returns address of local variable
and for this why the array variables values are still there ?

It is undefined behavior to try to access that pointer, meaning
things could "work",not work, work for a period of time, etc.

I've studied that when the function end the local variables loosing
their values as they
are distroyed and so If I want that they are not destroyed I should use
the static word before them...

You are returning a pointer to a local element of your array.
This array has auto storage, it goes out of scope when the function
ends.
You could have the caller pass in a pointer to storage where your
function can fiddle with.

[Christopher Layne]

xdevel wrote:

int * retArray()
{
int a[3] = {102,222,355};

printf("%p ", a);

return a;
}

and then in main()

int *p = retArray();
p++;
printf(" \n%p\n %d", p, *p);

Don't use static.

#include <stdio.h>
#include <stdlib.h>

void doArray(int *a, size_t c)
{
size_t i;

for (i = 0; i < c; i++) printf("%p ", (void *)&a[i]);
printf("\n");

return;
}

int main(void)
{
int a[3] = { 102, 222, 355 };

doArray(a, 3);

return 0;
}}

[xdevel]

Christopher Layne ha scritto:

Don't use static.

#include <stdio.h>
#include <stdlib.h>

void doArray(int *a, size_t c)
{
size_t i;

for (i = 0; i < c; i++) printf("%p ", (void *)&a[i]);
printf("\n");

return;
}

int main(void)
{
int a[3] = { 102, 222, 355 };

doArray(a, 3);

return 0;
}

yes but my question was relative to the situation of an array creation
inside a funcion :)

[Richard Heathfield]

xdevel said:

Hi,
in a function if I have

#include <stdio.h/* don't forget! */

int * retArray()
{
int a[3] = {102,222,355};

printf("%p ", a);

printf("%p ", (void *)a);

>
return a;

Don't do that. The array stops existing when the function returns, so its
address isn't much use to anyone.

}

and then in main()

int *p = retArray();
p++;
printf(" \n%p\n %d", p, *p);

The program's behaviour is undefined, because the value of p is
indeterminate and yet you've tried not only to use it but even to
dereference it.

the compiler warning me: ../c_test.c: In function 'retArray':
../c_test.c:24: warning: function returns address of local variable
and for this why the array variables values are still there ?

One possible outcome of undefined behaviour (although by no means the only
one) is that, on this particular occasion, the program behaves in the way
you observed, and has no unfortunate side-effects such as randomly
corrupting a single bit in your system directory.

--
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)

[xdevel]

Richard Heathfield ha scritto:

One possible outcome of undefined behaviour (although by no means the only
one) is that, on this particular occasion, the program behaves in the way
you observed, and has no unfortunate side-effects such as randomly
corrupting a single bit in your system directory.

thanks you are always clear and precise in your answers.

[Ark]

Christopher Layne wrote:
<snip>

Don't use static.

<snip>

int main(void)
{
int a[3] = { 102, 222, 355 };

doArray(a, 3);

return 0;
}

There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller. That's pretty darn hard to debug.
For the most part, I sorta bought into this (arrays are static or
dynamically allocated, which normally comes at a price of access
efficiency).
Is it overly paranoid? Any comments from safety- or mission- critical or
related fields?
Thank you,
-Ark

[Christopher Layne]

Ark wrote:

There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller. That's pretty darn hard to debug.

I wouldn't write sub-optimal code because of "could happen"'s. The reason I
said don't use static has to do with re-entrancy. Not that using static
automatically makes a function non-reentrance *in-use* - just that in his
particular example that was what he was shooting for.

Also, off-by-one errors are going to screw you if an array is auto or not.

[Ark]

Christopher Layne wrote:

Ark wrote:

>There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller. That's pretty darn hard to debug.

I wouldn't write sub-optimal code because of "could happen"'s.

That's the notion of "defensive programming". People do it all the time.
The reason I

said don't use static has to do with re-entrancy. Not that using static
automatically makes a function non-reentrance *in-use* - just that in his
particular example that was what he was shooting for.

Also, off-by-one errors are going to screw you if an array is auto or not.

True. But if I corrupt data only, I have a better chance of successful
debugging.

- Ark

[Christopher Layne]

Ark wrote:

That's the notion of "defensive programming". People do it all the time.

I tend to categorize defensive programming as being defensive against
internals (input lengths, maybe-cases, etc) and vague assumptions in code
(proper parenthesizing, not making ridiculous use of operator precedence that
not all may remember) rather than defending against myself, the programmer. I
guess what I'm trying to say is that by adopting a sub-optimal idiom because
you're afraid you *might* screw up is pulling a rug over the real issues.

>Also, off-by-one errors are going to screw you if an array is auto or not.

True. But if I corrupt data only, I have a better chance of successful
debugging.

- Ark

If your debugger is decent - it will be apparent regardless.

[Flash Gordon]

Ark wrote:

Christopher Layne wrote:

>Ark wrote:

>>There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller. That's pretty darn hard to
debug.

I wouldn't write sub-optimal code because of "could happen"'s.

That's the notion of "defensive programming". People do it all the time.

I would not count avoiding automatic arrays as defensive programming. It
does not prevent you from corrupting anything if you go off the end of
the array.

The reason I

>said don't use static has to do with re-entrancy. Not that using static
automatically makes a function non-reentrance *in-use* - just that in his
particular example that was what he was shooting for.

Also, off-by-one errors are going to screw you if an array is auto or
not.

True. But if I corrupt data only, I have a better chance of successful
debugging.

Depends on the quality of your debugging tools and how clearly your code
is written. In any case, you can easily add statements printing out the
value of the index before doing the access if you think there is a problem.
--
Flash Gordon

[Frederick Gotham]

Ark posted:

There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller.

Yes, you probably are -- which is why we check back over our code, paying the
utmost particular attention to these things.

--

Frederick Gotham

[Nils O. Selåsdal]

Ark wrote:

Christopher Layne wrote:
<snip>

>Don't use static.

<snip>

>int main(void)
{
int a[3] = { 102, 222, 355 };

doArray(a, 3);

return 0;
}

There is a school of thought that says automatic (basically, on-stack)
arrays are evil. Reason: as a mere mortal, I'm bound to make an
off-by-one mistake sooner or later, and do something unpredictable, like
corrupt the return address of my caller. That's pretty darn hard to debug.
For the most part, I sorta bought into this (arrays are static or
dynamically allocated, which normally comes at a price of access
efficiency).
Is it overly paranoid? Any comments from safety- or mission- critical or
related fields?

Wether an array is dynamically allocated, has static or auto storage
duration bears little impact on being able to do an off-by-one error.