jacob said:
Yes it does
int fn(void)
{
int a = 6;
}
int main(void)
{
a = 78;
fn();
}
Before the call to fn() the value of "a" is 78.
During the call to fn it is 6.
After the call to fn, the value of a REVERTS to its previous value
The last value defined is the first that goes away.
Last in, first out (LIFO)
i.e. a stack!
The name 'a' refers to two different variables, depending upon context.
That's a matter of the scope of the variable name, not it's lifetime.
The compiler would probably use a stack to keep track of scopes at
compile time; that doesn't say anything about how memory is managed in
the running program at run time.
If your argument were valid, it would apply equally well even if both
variables were declared 'static'. I don't believe it's your intent to
claim that statically allocated memory also requires a stack mechanism.
The relevant issue is the lifetime of the variables, not their scope.
However, while the lifetime of the variable named 'a' in 'fn' has ended
when the function returns, there's nothing in the standard that requires
that the memory allocated for that variable be deallocated. Not when
it's lifetime ends, and not at any other time, either. The fact that
most implementations deallocate the space at the earliest possible time
is a matter of QoI, not a requirement of the standard.
If, for example, it's inconvenient on a given system to deallocate less
than 512 bytes, I could imagine an implementation which groups together
several functions requiring a total of less than 512 bytes of space for
all automatic variables. It allocates all of their activation records as
soon as any of those functions gets called, and it deallocates all of
their activation records at the same time, only when none of them are
associated with a currently executing function call.
If variable "a" is not deallocated after the call to fn, this
would violate the standard and the C language of course!
Citation please?
Of course, that's not actually a problem, even if you did have a
supporting citation. The implementation I describe could delay
deallocation of the 'a' in fn() until after the deallocation of the 'a'
in main(). That wouldn't violate the requirement you assert (without
citation), because that deallocation would still be, as specified,
"after the call to fn". It just wouldn't be immediately after.
For dynamically allocated memory, the standard says "The free function
causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation." There is no comparable requirement
for deallocation of automatic memory.
If you experiment in different implementations of gcc, or other
compilers you will see that *sometimes* you can access the value
without crashing. But the fact that you can illegally access
some parts of the stack no longer valid doesn't mean there is
no stack. The same for your example.
True. The relevant feature that makes this NOT a stack is the fact that
the memory has not necessarily been been deallocated yet. Whether or not
it can be accessed by illegal constructs is irrelevant. The fact that
the activation records might be allocated in the order (main, fn) and
deallocated in that same order is what makes this not a LIFO, and
therefore not, even in the most abstract sense, a stack.
None since it uses a stack.
Besides you have yet to answer the question about a SINGLE example of
a real implementation that doesn't use a stack!
Real systems have been described (but not, I think, identified) which
don't use a stack in the commonplace sense of that word. That you insist
on ignoring the fact that this is the commonplace sense of the word is a
problem I can't do anything about.
The fact is, most of the people coming to this newsgroup with a question
about the 'stack' have a question which does not depend upon the
abstract concept of a stack, but rather on the far more concrete and
commonplace idea of a contiguous stack which grows and shrinks only at
one end, and the misconception that the C standard requires such a stack.
