|Re: [go-nuts] stack vs heap allocation||Adam Langley||11/11/09 5:49 PM|
On Wed, Nov 11, 2009 at 5:45 PM, inspector_jouve <kaush...@gmail.com> wrote:
> Documentation states that it's perfectly legal to return a pointer to
> local variable. I can't make sense of this statement. Does it mean
> that local variables are not allocated on stack?
Local variable allocation is up to the compiler. Obviously most local
> What is the structure of stack then?
The stacks are heap-allocated and non-contiguous in memory. Each
> Another issue is array allocation. Is array allocated on stack?
It might be. See above.
|unk...@googlegroups.com||11/11/09 5:45 PM||<This message has been deleted.>|
|unk...@googlegroups.com||11/11/09 6:02 PM||<This message has been deleted.>|
|Re: [go-nuts] Re: stack vs heap allocation||Nigel Tao||11/11/09 6:20 PM|
2009/11/12 inspector_jouve <kaush...@gmail.com>:
> Compiler cannot know this. Struct allocated on stack may have pointers
> to other structures allocated on stack.
I think that the current, simple-but-it-works heuristic is that if you
|Re: [go-nuts] Re: stack vs heap allocation||Ian Lance Taylor||11/11/09 9:02 PM|
inspector_jouve <kaush...@gmail.com> writes:> to other structures allocated on stack. This issue can be resolved
> dynamically, with the help of garbage collector. Effectively, this
> means there's no stack allocation in a usual sense. By usual sense I
> mean that upon return from function, stack pointer
> just gets adjusted, and all pointers to local variables automatically
> become illegal.
> The problem with your response ("up to compiler") is that I cannot
> imagine ANY kind of compiler, under ANY reasonable assumptions, to be
> consistent with these statements while
> preserving a regular notion of stack. Could you please describe a
> model of stack (just as example, to illustrate the idea)
The compiler can know this. The compiler knows whether you ever take
the address of a variable.
In the simplest case: if you take the address of a variable, it is
always stored on the heap. If you don't save a copy of its address,
the garbage collector will get it. But if you don't take the address
of a variable, then it can be stored in the stack frame as for C/C++.
It's not hard to do better than that in some cases, but the general
rule is valid and reliable.
> On Nov 11, 8:49 pm, Adam Langley <a...@golang.org> wrote:
|unk...@googlegroups.com||11/12/09 5:36 AM||<This message has been deleted.>|
|Re: stack vs heap allocation||Dan||11/12/09 1:48 PM|
> Suppose you pass a struct to a function f as a parameter by value.
> Function f can take the address of this struct and store it somewhere. Your
> logic suggests that struct should be allocated
> in a heap. However, caller does not know anything about it - he passes
> struct in a stack!
The compiler can make a copy of the struct on the heap at the
beginning of the function.
You passed the parameter by value, so you can't expect the pointer to
point to your external struct object. Even if the compiler wouldn't
copy it to the heap, you have already made another copy on the stack
before calling the function!