# Go Compiler nil Pointer Checks

DevFeed: [Go Compiler nil Pointer Checks](<https://devfeed.tech/articles/go-compiler-nil-pointer-checks-22105.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2014/09/go-compiler-nil-pointer-checks.html>)

Published: 2014-09-01T00:00:00Z

Content type: tutorial

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Code](<https://devfeed.tech/topics/code.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [ardan-labs](<https://devfeed.tech/tags/ardan-labs.md>), [blog](<https://devfeed.tech/tags/blog.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [exception](<https://devfeed.tech/tags/exception.md>), [go](<https://devfeed.tech/tags/go.md>), [go-programming](<https://devfeed.tech/tags/go-programming.md>), [golang](<https://devfeed.tech/tags/golang.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [memory](<https://devfeed.tech/tags/memory.md>), [programming](<https://devfeed.tech/tags/programming.md>)

## AI overview

This article explains when the Go compiler inserts nil pointer checks and when it relies on hardware to detect invalid memory access. It shows how a nil pointer write produces a runtime panic and stack trace, and how omitting a compiler check can reduce generated code.

## Source excerpt

Introduction I was thinking about how the compiler looks to protect the code we write when it can. Invalid memory access checks are one type of safety check the compiler adds to our code. We might think that this "extra code" is hurting our performance and maybe over billions of iterative operations it is. However, these checks can prevent our code from causing damage to the systems we are running on. The compiler is essentially reporting and finding bugs, making the code we write safer to run. Even with this in mind, Go wants to be fast and if the hardware can catch a problem, it will let it. One of these cases is with the detection of invalid memory access. There are times when the compiler will add a nil pointer check into our code and times when it doesn't. In this post we will explore one case where the compiler leaves it up to the hardware to detect invalid memory access and one case where the compiler adds a nil pointer check. Hardware Only Checks When the compiler can depend on the hardware to check for and report invalid memory access, the compiler can produce less code which helps with performance. If our code attempts to read or write to address 0x0, the hardware will throw an exception that will be caught by the Go runtime and reported back up to our program in the form of a panic. If the panic is not recovered, a stack trace is produced. Here is an example that attempts to write to memory address 0x0 and the corresponding panic/stack trace: