2

When I'm on SO I read a lot of comments guiding (Especially in C)

"dynamic allocation allways goes to the heap, automatic allocation on the stack"

But especially regarding to plain C I disaggree with that. As the ISO/IEC9899 doesn't even drop a word of heap or stack. It just mentions three storage duriations (static, automatic, and allocated) and advises how each of them has to be treat.

What would give a compiler the option to do it even wise versa if it would like to.

So my question is:

Are the heap and the stack physical existing that (even if not in C) a standardized language can say "... has to happen on heap and ... on the stack"?

Or are they just a virtuell system of managing memory access so that a language can't make rules about them, as it can't even be ensured the enviroment supports them?

In my knowledgebase only the second would make sense. But I read allready many times people writing comments like "In language XY this WILL happen on the stack/heap". But if I'm right this had to be indeterminable as long the language isn't just made for such systems which guarantee to have a stack and heap. And all thoose comments would be wrong.

Thats what lead me to ask about this question. Am I that wrong, or is there a big error in reasoning going around about that?

trincot
  • 317,000
  • 35
  • 244
  • 286
dhein
  • 6,431
  • 4
  • 42
  • 74
  • possible duplicate of [What and where are the stack and heap?](http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) – MatthiasB Dec 16 '14 at 10:44
  • @Matthias Serious? This post is asking about heap and stack to be seen as more a virtual or a physicall system. I read that post you linked before asking this question and I can say with pure conscience that there isn't even the aspect of the question i asced here, picked up. So no it is absolutly not a duplicate. – dhein Dec 16 '14 at 10:52
  • [this answer](http://stackoverflow.com/a/13326916/1810521) seems to be a good answer to your question, also in respect of a C compiler. – MatthiasB Dec 16 '14 at 12:30
  • To quote the relevant segment: "Although most compilers and interpreters implement this behavior similarly in terms of using stacks, heaps, etc, a compiler may sometimes break these conventions if it wants as long as behavior is correct. For instance, due to optimization a local variable may only exist in a register or be removed entirely, even though most local variables exist in the stack..." – MatthiasB Dec 16 '14 at 13:03
  • @MatthiasB Yeah thats true, that is the direction My question goes. But his answer was not that depth as that would satisfy me. (Same as, why I'm not acepting Colonel Thirty Two answer, whcih is anyway good and upvote worth) But I want also to know is this a pure virtual model, or are there also hardware versions of it, that in thoose enviroments it would be 'predictable'. So thanks for your effort marking me that up. But trust me, this question isn't a duplicate. – dhein Dec 16 '14 at 13:27
  • Maybe you could specify the question a bit in this direction? At the moment it reads more like "Why is everyone using the term stack/heap when it in reallity is incorrect?". If I understood correctly, you are looking for something in the lines of "Does a compiler/platform exist where the concept of stack/heap is not (or is?) used" ore something in this direction? – MatthiasB Dec 16 '14 at 13:37
  • I'm asking for "are stack/heap a pure virtual model? -> The enviroment can decide of the way it is or is not implemented. Or exist memory devices holding a stack and a heap where you HAVE TO use one of both. -> There had to exist rules when what will be used." I will try to clarify. – dhein Dec 16 '14 at 13:49

1 Answers1

2

You are correct in that the C spec doesn't require the use of a heap or stack, as long as it implements the storage classes correctly.

However, virtually every compiler will use stacks for automatic variables and heaps for allocated variables. While you could implement a compiler that doesn't use a stack or heap, it probably wouldn't perform very well and wouldn't be familiar to most devs.

So when people say "always", they really mean "virtually always".

Colonel Thirty Two
  • 23,953
  • 8
  • 45
  • 85
  • Just another aspect: imagin a memoryblock of allocated storage type. It is allocated and freed in a scope which isn't left wtihout deallocating the storage for any case. Wouldn't it be a good job of the compiler just using the memory on the stack if the block is small enough? So for this case: Wouldn't the "malloc will be on the heap" statement even be wrong in this case? ;) – dhein Dec 16 '14 at 10:46
  • @Zaibis: the compiler can't predict in general when a function will be called, so it doesn't know how deep in the stack the call will be made => can't know what "small enough" would be. (That's assuming the compiler knew how much stack is available at all - which it can't generally either, the runtime/OS can be configured with different stack sizes/limits.) – Mat Dec 16 '14 at 11:09
  • @Mat Ok, About that how deep in thing I agree. But the compiler can know (it can even set!) the stack size. So it can make a relation to whats small and what is not really small. So lets say we have a 2MB stack. And some one is malloc()ing a block of 4 byte which is in any way freed before another one in that scope is allocated or the scope is left. If you go that deep, that it depand on 4 byte, than you should not turn on compiler optimization nor rely on "the programm won't crash". It is unusual to do so, maybe there isn't even any compiler doing this. But fact is: it wouldn't break any law! – dhein Dec 16 '14 at 12:02
  • @Zaibis: the linker sets that sort of thing up, not the compiler. And OS limits can override it potentially. If there's any gain to optimizing small allocs in your code, do that yourself. – Mat Dec 16 '14 at 12:18
  • @Mat Oh... Now as I think about it, there isn't any sense of the compiler setting this up. you 2, me 0. But at all: Letting the compiler do this kind of optimization would be valid. And should I ever code a compiler.... I will let it do this just to be able to say "you can't predict! Following compiler [...] doesn't do so and is still conform to ISO/IEC..." :D – dhein Dec 16 '14 at 12:30