Comment 1:

The spec appears to be incorrect here.  The language permits you to call a pointer
method with a nil pointer.

Labels changed: added priority-soon, documentation, removed priority-triage.

Owner changed to @griesemer.

Comment 2 by eric.atienza@mydoceapower.com:

I've updated the example here http://play.golang.org/p/lzQAC_j7Oy
What you said is that it's correct to call a method on a nil pointer. Agreed, this would
be a.b.Check()
but here what we've got is a.b.c.Check() where b (in the middle) is nil.
in the Check method, the receiver address is 0x0c ( apparently offset of c in B struct),
obviously not nil. There is no way to check that this address is correct (any attempt to
dereference it leads to a panic)

Comment 3:

Thank you for this example. This is terrible. We may need to rethink
how the semantics here.

Comment 4:

I think we still need to adjust the spec, but now that I see what is going on I agree
that this example ought to panic.  We may need to add an explicit nil check to every
automatic pointer field dereference when calling a method.

Labels changed: added compilerbug.

Comment 5:

Yes but it's also not just methods:
type T struct { x, y int }
var t *T
p := &t.y
What do we say about p here? Right now p is 4, so it is != nil yet
dereferencing it crashes. That's a class of pointer I don't think we
intended to expose.

Comment 6:

I think there are two approaches:
1) do early checks; i.e., possibly add an extra instruction to cause a nil-panic if
necessary
2) do late checks; i.e., only if a value pointed to via a pointer is actually _used_
(this may still require early checks because of offsets that are greater than 4K or
whatever the page size)
Either way requires some adjustments in the spec. Sigh.

Comment 7:

The problem with 'late checks' is that they cannot be programmed around.
It is easy to write code that avoids dereferencing nil.
It is nearly impossible to write code that avoids dereferencing 4
(from the last example).
I think we'll need to do something more like 'early checks' (although
defining exactly what is checked is tricky) and then the compiler will
be free to omit checks that it can prove don't change the semantics.
For example
    x = t.y
doesn't need to explicitly check t for nil because the t.y read will fault.
But perhaps
    x = &t.y
does need to check t for nil.
Not saying that for sure, but it's a possibility.

Comment 8:

this discussion duplicates issue #4238.

Comment 9:

It seems to me that checking (explicitly, in code) pointers for being nil is still not
necessary (assuming that's being caught by a signal). Instead, I think the "bad" case
can be reduced to checking for (explicitly, in code at run time) the pointer arithmetic
`p` operand to be non zero while/whenever computing `p+field_offset`, where p ==
&some_struct_instance.

Comment 10:

Status changed to Duplicate.

Merged into issue #4238.

Comment 11:

Labels changed: added size-xl.