Undefined behavior

[Takashi Kawachi]

I read LLVM Project Blog(*1), and wonder whether the same undefined
behavior does exist in golang or not?

Use of an uninitialized variable
Signed integer overflow
Oversized Shift Amounts
Dereferences of Wild Pointers and Out of Bounds Array Accesses
Dereferencing a NULL Pointer
Violating Type Rules

At least, Specification(*2) doesn't contain a word "undefined".

*1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
*2 http://golang.org/doc/go_spec.html

--
Takashi Kawachi
tkawachi at gmail.com

[Keith Rarick]

All of those are defined by the spec, except that
I couldn't find an explicit statement that dereferencing
nil causes a run-time panic (analogous to "Receiving
from a nil channel causes a run-time panic").

Should I file a doc bug?

kr

[Evan Shaw]

On Mon, May 23, 2011 at 1:58 PM, Takashi Kawachi <tkaw...@gmail.com> wrote:
> Use of an uninitialized variable

All variables are initialized to a "zero" value that is defined by the spec.

> Signed integer overflow

The result wraps around.

> Oversized Shift Amounts

There is no such thing in Go.

> Dereferences of Wild Pointers and Out of Bounds Array Accesses

It's not possible to have a wild pointer unless you use the package
unsafe (or you're using a buggy package which uses unsafe). However,
once unsafe is used the results are not well-defined, but it should be
obvious when it's happening in your own code.

If a slice or array index out of bounds, a run-time panic occurs.

> Dereferencing a NULL Pointer

You mean "nil". ;) This is undefined in the spec, but I suspect the
spec should say it causes a run-time panic. That's what the runtimes
do right now.

> Violating Type Rules

Go doesn't allow this without using the package unsafe.

- Evan

[Brad Fitzpatrick]

Sure. As long as you've spent a minute double-checking yourself & checked for dup bugs and you're mostly confident, go for it. Bugs can always be closed if they're invalid. Don't worry too much about it.

[Takashi Kawachi]

Thank you for replies.
Go spec seems to be more safer and readable than C :)

--