Array scope

[George_K]

Consider this lines of code:

*int make_array();
void get_array(int *array_pointer);

*int make_array()
{
int i;
array[20];
for(i=0,i<=19,i++)
{
array[i]=i;
}
return array;
}

void get_array(int *array_pointer)
{
for(i=0,i<=19,i++)
{
printf("%d",*array_pointer);
array_pointer++;
}
}
get_array(make_array());

I made this code in order to make my question.
Does the last line of code make sence?
Does the array exists when make array has ended?
When i run such code i don't have a problem.
Am i lucky that the items are still there and unchanged?

[Alex Fraser]

"George_K" <ge************@hotmail.com> wrote in message
news:52**************************@posting.google.c om...

Consider this lines of code:

*int make_array();
You mean:

int *make_array();

Or, better:

int *make_array(void);
void get_array(int *array_pointer);

*int make_array()
Same again.
{
int i;
array[20];
You mean:
int i,
array[20];

Or:
int i;
int array[20];
for(i=0,i<=19,i++)
You mean:
for (i = 0; i <= 19; i++)

The more usual form for the test would be "i < 20". See if you can think of
any possible reasons for this.
{
array[i]=i;
}
return array;
Causes undefined behaviour (or if not now, then when you try to access the
pointed-to array later); array ceases to exist when the function ends.
}

void get_array(int *array_pointer)
{
You need to declare i:
int i;
for(i=0,i<=19,i++)
The same comments as the previous for loop apply here.
{
printf("%d",*array_pointer);
array_pointer++;
}
}

get_array(make_array());

I made this code in order to make my question.
Does the last line of code make sence?
Apart from "get_array" being a poor choice of function name IMO, there is
nothing wrong with the last line in itself.
Does the array exists when make array has ended?
No. If you want it to, either (1) declare it in the calling function and
change make_array() so that it accepts a pointer and the size of the array,
or (2) use malloc() (remembering to free() the array later).
When i run such code i don't have a problem.
Am i lucky that the items are still there and unchanged?

Yes. Or unlucky, depending on how you look at things.

Alex

[Richard Bos]

ge************@hotmail.com (George_K) wrote:

Consider this lines of code:

*int make_array();
void get_array(int *array_pointer);

*int make_array()
{
int i;
array[20];
for(i=0,i<=19,i++)
{
array[i]=i;
}
return array;
Oops. You've just returned a pointer to a variable whose life-time has
ended. Use this pointer in any way and you have undefined behaviour. See
also <http://www.eskimo.com/~scs/C-faq/q7.5.html>.
}

void get_array(int *array_pointer)
{
for(i=0,i<=19,i++)
{
printf("%d",*array_pointer);
array_pointer++;
}
}

get_array(make_array());

I made this code in order to make my question.
Does the last line of code make sence?
The whole make_array() function is broken. This line in itself is not
the problem. Fix make_array(), and the last line is OK.
(Of course, if you fix make_array() by calling malloc(), you now need to
make sure that get_array() either free()s that memory or saves the
pointer somewhere global so it can be free()d later, and making array
static has its own problems, but those are secondary, and solvable. As
it is, it is broken.)
Another problem is the use of magic numbers for the size of the array,
but that can easily be solved in production code using a #defined
constant.
Does the array exists when make array has ended?
Nope.
When i run such code i don't have a problem.
Am i lucky that the items are still there and unchanged?

Unlucky, I'd say. If you crash, you at least know that you've got a
problem. If it appears to run, it will probably decide to start crashing
just as you're demonstrating your program to your biggest client...

Richard

[Christopher Benson-Manica]

Richard Bos <rl*@hoekstra-uitgeverij.nl> spoke thus:

Unlucky, I'd say. If you crash, you at least know that you've got a
problem. If it appears to run, it will probably decide to start crashing
just as you're demonstrating your program to your biggest client...

You mean like when Bill Gates was demonstrating his product's alleged
plug-and-play capability at a major conference?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Stuart Gerchick]

ge************@hotmail.com (George_K) wrote in message news:<52**************************@posting.google. com>...

Consider this lines of code:

*int make_array();
void get_array(int *array_pointer);

*int make_array()
{
int i;
array[20];
for(i=0,i<=19,i++)
{
array[i]=i;
}
return array;
}

void get_array(int *array_pointer)
{
for(i=0,i<=19,i++)
{
printf("%d",*array_pointer);
array_pointer++;
}
}
get_array(make_array());

I made this code in order to make my question.
Does the last line of code make sence?
Does the array exists when make array has ended?
When i run such code i don't have a problem.
Am i lucky that the items are still there and unchanged?

another solution could be to make the array static. But the array as
it stands goes away as soon as you leave the function. It might still
be around, it might not. But you are looking at something that no
longer official exists

[Eric Sosman]

Stuart Gerchick wrote:

ge************@hotmail.com (George_K) wrote in message news:<52**************************@posting.google. com>...
[function returning pointer to `auto' array]

another solution could be to make the array static. But the array as
it stands goes away as soon as you leave the function. It might still
be around, it might not. But you are looking at something that no
longer official exists

s/official//

The disappearance of an `auto' variable when its
containing block exits is not a purely academic concern
nor a mere matter of pedantry. On most C implementations
`auto' variables are allocated on a stack, and the stack
is popped when a function returns (and sometimes when an
inner block exits, too). The next function you call (or
block you enter) will overlay the same stack memory with
its own `auto' variables, wiping out whatever the first
function (block) stored there.

Even without any subsequent function call, many C
implementations feel free to modify the stack memory
beyond the deepest current block. For example, the
context switch generated by a hardware interrupt may well
push registers, program counter, and other context onto
the stack, once again scribbling all over the memory
addressed by your bogus pointer.

On comp.lang.c we like to say things like "evaluating
`INT_MAX + 1' may make demons fly out of your nose."
From the point of view of the C language Standard this
is correct -- but in the real world it is, of course,
utter nonsense. Returning a pointer to an `auto' variable,
though, is an error of a different kind: not only *can*
it cause strange trouble, it almost certainly *will* do
so, and not only on the DeathStation 9000 but on real live
machines just like those you use every day. Don't Do That.

--
Er*********@sun.com