<pre class="notranslate">Tested with latest tip.

ENODATA is not supported on e.g. FreeBSD but ENOATTR is supported more
widely. In Linux it is a synonym for ENODATA.

The attached patch makes ENOATTR work on Linux.</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/753/0/err.diff" rel="nofollow">err.diff</a> (1448 bytes)</li>
</ol>
<p dir="auto">by <strong><a href="mailto:m@mihasya.com">m@mihasya.com</a></strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. in a method, create an array using literal syntax
2. take that array's slice using [:] syntax
3. return the slice
4. try to access the slice from caller

Simplest reproducing program, courtesy of dominikh (Dominik Honnef) who helped me look
at this: 
<a href="http://play.golang.org/p/Yl6EXET0fc" rel="nofollow">http://play.golang.org/p/Yl6EXET0fc</a>

My original program, reproducing roughly the steps that triggered this in a real project
(much more elaborate):
<a href="http://play.golang.org/p/s1WGRen-te" rel="nofollow">http://play.golang.org/p/s1WGRen-te</a>

What is the expected output?
0 3 foo
1 3 bar
0 3 foo
1 3 bar

What do you see instead?
0 3 foo
1 3 bar
0 3 foo
1 4457167 [string too long]

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

Which version are you using?  (run 'go version')
1.1 (dominikh confirms this happens on tip as well)

Please provide any additional information below.
This is a strange and elusive bug; essentially, when using a slice that is produced
using the [:] notation on an array as a return value, the caller gets a bogus pointer.
When I initially came across this bug, I was getting "invalid memory address or nil
pointer dereference" panics in the json Marshal function when trying to serialize
the return value (I was testing an HTTP framework, so I just had a method return the
slice of [2]string{foo, bar}). When I tried to printf the value it was trying to pass to
Marshal, it printed a bunch of binary data with strings that I recognized from other
parts of the program, obviously causing serious concern.

Below are 2 programs that will reproduce this in various forms. dominikh from #go-nuts
helped me look at this and actually narrowed it down a bit further than my initial
repro, which just reproduced the sequence of events that happened in my program. His
notes below:

"These are all the details I could find:

- It breaks when using method values; it doesn't break when using
function values.
- It breaks when allowing inlining; it doesn't break when not allowing
inlining
- It breaks both with Go 1.1 and Go tip, so that makes bisecting it
somewhat easier."

Additional "fun" info:
- if you call printf("%p", foo[:]) in the "broken" method in the
second program, it "fixes" the issue; I'm guessing this tips off the compiler
somehow. I discovered this while trying to see if I could demonstrate the pointer having
the wrong address</pre>