8

I'm reading a book called The Go Programming Language, and in the 2nd chapter about pointers the following is written

It is perfectly safe for a function to return the address of a local variable. For instance, in the code below, the local variable v created by this particular call to f will remain in existence even after the call has returned, and the pointer p will still refer to it:

var p = f()
func f() *int {
    v := 1
    return &v
}

I totally don't get this, a local variable is supposed to be destroyed after the function execution. Is it because maybe v is allocated on the heap. I know in C if you allocate space using malloc it won't be destroyed after function execution because it's on the heap.

Improve this question
5
  • 5
    Go is not C. Go has a garbage collector that manages memory for you. Commented Oct 25, 2018 at 19:11
  • 3
    "local" variables don't work the same way in Go as they do in C. Whether a variable is allocated on the stack or the heap is determined by the compiler at compile time based on escape analysis, not just based on whether it's a pointer or not (as it is in C). Generally speaking, you can simply trust Go's garbage collector. It'll manage memory for you, and the language usually prevents situations where you could access a stale pointer or unallocated memory (segfaults in Go generally come from trying to access a nil pointer). Commented Oct 25, 2018 at 19:16
  • Accessing a nil pointer shouldn't ever segfault, but it will trigger a panic. Commented Oct 25, 2018 at 19:19
  • 1
    SIGSEGV is in fact considered as a segmentation fault, or the fault caused by invalid memory reference no matter how you call it. Commented Oct 25, 2018 at 19:23
  • 1
    Local refers to the scope of a variable, not how the value is allocated. The spec is silent on the details of allocation for all variables. Commented Oct 25, 2018 at 20:52

2 Answers 2

Reset to default
18

Go isn't C. Despite similarities, it is much higher-level. It utilizes a complete runtime with a green thread scheduler and garbage-collecting memory manager. It will never collect memory so long as it has live references.

The Go compiler includes a stage called "escape analysis", where it tracks each variable to see if it "escapes" the function in which it is declared. Any value that can escape is allocated on the heap and managed by garbage collection; otherwise, it is (usually) allocated on the stack.

You can find more information on the subject:

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

do you have any materials where I can learn more about this, please?
Just added some references.
0

Golang has garbage collector(GC) but C doesn't have, which means Go has a GC that can manage memory for you. for Golang: Each variable in Go exists as long as there are references to it no matter it's a local or global variable.

I find this on Golang FAQs Doc, hope it will help:

Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.

The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.