<p dir="auto">by <strong>Vova616</strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
foo.c:
#include "_cgo_export.h"

void test() {
    Test(1,2,3);
}

foo.go:
package main

//void test();
import "C"
import "fmt"

//export Test
func Test(val C.int, val2 C.double, val3 C.double) {
    fmt.Println(float64(val), float64(val2), float64(val3))
}

func main() {
    C.test()
}


What is the expected output?
1 2 3

What do you see instead?
1 9.80967354e-315 5.304989477e-315

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

Which operating system are you using?
Windows 7 64bit

Which version are you using?  (run 'go version')
go version go1.1.2 windows/386
also
go version devel +1d0a0a267088 Wed Aug 14 22:18:49 2013 +0400 windows/386

Please provide any additional information below.

Changing (val C.int -&gt; val C.double) fixes the problem.
"tapir" from github confirmed similar code was working fine on Arch linux
32bit but not on windows.</pre>
<pre class="notranslate">The spec at the moment permits _ methods in signatures, like:

type A interface{
   _()
}

and such interfaces cannot be implemented, per a prior assessment of this problem (see
<a href="https://golang.org/issue/5691" rel="nofollow">issue #5691</a>). That said, there are open questions related to this that are unclear from
the spec. For instance:

1) Given A, and a type B defined like A, and variables a, b of type A, and B,
respectively, is: a = b permitted at compile-time? That is, are type A and B identical?

2) Given A, and a type B interface { _(); _() } with accordingly typed variables a, b,
is: a = b permitted? That is, are type A and B identical now?

There are several ways we can fix this in the spec. Here are two possibilities:

1) Disallow _ methods in interfaces altogether since it's never possible to implement
such an interface, never possible to call the _ method, and the contents of such
variables is always nil. Cons: we permit _ identifiers everywhere else.

2a) Permit _ methods in interfaces but any interface containing (at least) one _ method
is different from any other interface type unless they both have the same name.

2b) Permit _ methods in interfaces but any interface containing (at least) one _ method
is different from any other interface type including itself (sort of the NaN of
interfaces: NaI).

3) Maintain the _ methods in the method set, every single one of them. So interface
types that have the same non-blank methods are identical only if they have the same _
methods. That seems like a bad idea since it would require comparing signatures, and
also makes compiler internal sorting very complicated.

I am leaning towards 2a or 2b. 2b seems cleaner but precludes an easy pointer comparison
to check for type equality w/o further checking that no interface with _ method is
involved.

This is an esoteric corner case but affects how (compiler-) internally method sets are
represented and sorted.</pre>