<p dir="auto">by <strong>Bailey.D.R</strong>:</p>
<pre class="notranslate">This bug involves a fairly simple usage. There are three parts to this program:

1) A static library (named libhello.a) written in C, exposing function
"say_hello".

2) A package in Go (named hello), exposing func "SayHello", which calls into
the C library.

3) A tool using the hello package (named hello_main) that calls SayHello.


The strange part is that when I compile the static library with -g -O2 -fPIC -m64
-pthread -fno-common, the build succeeds.... but fails with a runtime error:

panic: runtime error: call of nil func value
[signal 0xb code=0x1 addr=0x0 pc=0x0]

goroutine 1 [syscall]:
hello._Cfunc_say_hello(0x2018, 0xb1a2)
    /var/folders/p_/mhydwmzj78n6s6xvf9zly6bm0000gn/T/go-build218171681/hello/_obj/_cgo_defun.c:42 +0x2f
hello.SayHello()
    /var/folders/p_/mhydwmzj78n6s6xvf9zly6bm0000gn/T/go-build218171681/hello/_obj/hello.cgo1.go:10 +0x18
main.main()
    /Users/duane/Projects/go-bug/src/hello_main/hello_main.go:6 +0x18

goroutine 2 [syscall]:
created by runtime.main
    /Users/duane/repo/go/src/pkg/runtime/proc.c:221


However, if I move the c file in with the go package "hello" directory, and
allow it to be compiled in without going through the static library intermediary, it
runs fine.

The two build trees are attached for reference. Simple cd into the directory and
"bash ./build.sh" to compile and run it.

As for my system: I'm running at tip ("go version weekly.2012-03-27
+95dddad64860") on OSX Lion 10.7.3. GCC is version
"i686-apple-darwin11-llvm-gcc-4.2"; however, switching to "vanilla"
gcc or to clang makes no effect.</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/3755/0/go-bug.tar" rel="nofollow">go-bug.tar</a> (8704 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/3755/0/go-working.tar" rel="nofollow">go-working.tar</a> (8192 bytes)</li>
</ol>
<pre class="notranslate">Overview
This proposal would allow bidirectional type conversions between all of the builtin
scalar numeric types and the builtin "bool" type. The syntax and grammar of
the language already allows these conversions but the current compiler doesn't implement
these particular conversions and gives error messages. As has been standard since
"C" was developed the numeric value of 0 is considered "false" and
any non-zero numeric value is considered "true", but the canonical value of
"true" is numeric 1.

Description
Today if you want to convert between a numeric type and the "bool" type you
have to create a function to do it. For example:
<a href="http://play.golang.org/p/jUlDoCCI5N" rel="nofollow">http://play.golang.org/p/jUlDoCCI5N</a>

var itob = func(int i) bool {
    if i == 0 {
        return false
    }
    return true
}

var btoi = func(bool b) int {
    if b {
        return 1
    }
    return 0
}

These functions also define the semantics I propose for the conversions proposed.

Because there are currently no generic functions and no trinary operator one often has
to implement multiple versions of the above functions.

If this proposal is accepted and implemented the following two conversions and others
like them would no longer generate the following compiler errors in the cg compilers:

var i int= 1
b := bool(i)
i := int(b)

./bool.go:24: cannot convert i (type int) to type bool
./bool.go:25: cannot convert b (type bool) to type int

Justification
After several years of Go programming I long for this functionality. I often need to
convert a slice of numbers to bools or bools to numbers in a loop. Having to call a user
defined function for each conversion is slow and in many (all) cases these conversions
can be handled without branches and in any case these conversions can and should be
inlined.

Implementation
The implementation requires that the compilers be updated to allow these conversions and
generate code for each case. The scalar numeric types affected are:
uint8, uint16, uint32, uint64, int8, int16, int32, int64, float32, float64, uint, int,
byte, rune

Since I have seen integers passed as a uintptr using OpenGL via Cgo I suggest that the
type "uintptr" also be allowed as a numeric type that can be converted to and
from a "bool".

Documentation
In the "Conversions" section of the "The Go Programming Language
Specification" the following line would change from:
"x's type and T are both integer or floating point types.""
to:
"x's type and T are both integer, floating point, or bool types."

Issues
I am unsure of how to handle floating point +0.0 and -0.0. Right now I think only
regular 0.0 is "false" but I am unsure about this.

Related Issues
<a href="https://golang.org/issue/6011" rel="nofollow">https://golang.org/issue/6011</a>
This is similar to #6011 except the proposed syntax is different. I believe the syntax
proposed here is more consistent with the spirit of the language and is simpler too.
Importantly, I would like to point out that the Type Assertion syntax isn't needed here
because any numeric value can be converted to a "bool" and any
"bool" can be converted to a numeric value so these conversions can never fail.</pre>