Quote:
This will not take memory from heap. This would be allocated from stack because this is a local variable and you aren't using malloc() / any alloc() functions.
How come????
The arrary is going to be on the heap of the process memory only.
However, it's the pointer variable 'a' is going to be over the stack frame of the function using that as it's local.
---------- Post updated at 01:16 PM ---------- Previous update was at 12:51 PM ----------
@aliter ,
Thanks for the information, that's definitely going to be a direction, I'll need to investigate a bit further for my own shake.
To sum up, do you mean to say, in other words, that it's the implementation of heap which is going to be different in different systems?
That's what I'm aware of and most logical thing to conclude of when two operating systems are developed altogether differently and separately.
Also its never the compiler which actually allocates these heap related object/variables rather the OS memory manager allocates them at the run time only.
Its perfectly okey to have different implementations of the actual resident memory area of a heap based variables. The running process (which owns these variables) just treat them at a memory location that's always upper bound and assumes such memory area altogether grows outwards (the stack grows in the direction opposite to the heap, which is inwards).
The whole thing could also be implemented as to simulate this behavior and that's what many virtual memory implementations do.
Not only that, the whole process memory area could altogether be implemented differently (over different platforms) but they give the same feeling to the running process by exposing similar
interfaces and
response from the operating platform the process is executing on.
Your information was important to me more because of the fact you have clubbed FreeBSD & Linux implementations together.
Might be Linux code implementing these behaviors find it's root in BSD repository tree only, but I'm just speculating here.