santosh said:
Keith Thompson wrote: [...]
That raises an interesting question about the word "heap".
The words "stack" and "heap" occur nowhere in the C standard. It's
(too) common to refer to the area used to allocate automatic objects
as the "stack", but I think most of us agree that this is misleading
and incorrect.
Can a perverse but conforming implementation use the "heap" for
automatic objects. As long as their properties, as dictated by the
standard, are honoured, I don't see why they should be allocated from
a stack.
Sure. It's not even necessarily perverse; I think that some IBM
mainframe systems do this.
I may be wrong, but it was my impression that a stack is simply a LIFO
data structure. It doesn't have to have any specific hardware support.
On stackless architectures, a LIFO may have to be simulated by the C
implementation, for auto objects.
From a computer science point of view, yes, a "stack" is simply a LIFO
data structure, which can be implemented in any number of ways
(contiguous array, linked list, etc.). But if you're talking about a
specific CPU architecture, the phrase "the stack" typically refers to
the CPU-specific structure I described above. If someone says that
automatic variables are allocated on "the stack", that tends to imply
the CPU-specific structure -- at least, it does to me.
Yes. It curious why so many students of C are bursting to know where C
objects are stored. I would've thought that an assembly language or
machine architecture course would be the proper place to recieve such
information.
Sure, but knowing something about the underlying architecture can be
helpful in understanding *why* C defines things the way it does.
Though the standard doesn't use the word "stack", the way automatic
objects are allocated and deallocated is almost certainly motivated in
part by the kind of CPU-specific stack implementation described above.
If you have this kind of system stack, meeting the standard's
requirements for automatic objects is straightforward. If you don't,
you have to go to some extra effor to "fake it". The danger is
assuming that "all the world's a <whatever>".
By contrast, consider the way Perl works. Much of Perl's syntax is
borrowed from C, and it has functions and things that look, and
*usually* act, very much like C automatic objects. But they're not
necessarily allocated and deallocated in a stack-like manner. For
example, the equivalent of:
int *create_new_int(void)
{
int local;
return &local; /* BAD! */
}
actually works in Perl; the object isn't deallocated on exit from the
function as long as anything refers to it. In effect, everything is
heap-allocated and garbage-collected. Some knowledge of CPU
architecture is helpful in understanding *why* C doesn't work this
way.
In many architectures the same memory is used for both the stack and
the heap. The former typically grows down from the high end of the
address space, while the latter grows in the opposite direction.
Ok. In that case, I'd say that "the heap" could refer to the region
of memory currently allocated for management by malloc and free; this
region may grow or shrink over time (in, ironically enough, a
stack-like manner).
I don't think so. For example in x86's segmented memory model, we can
have multiple heaps which are not contiguous. Even multiple objects
needn't be contiguous with one another.
Then that's an argument *against* talking about "the heap" in general.
I was speculating that, unlike the phrase "the stack", the phrase "the
heap" might be generic enough to refer to the malloc/free mechanism of
any possible C implementation. But if some such implementations have
multiple things they call "heaps", then "the heap" becomes ambiguous
and/or misleading.
[...]
