Does the code work other than producing a warning?

It’s actually a bit hard to trace in the real code, but the following code:

package main

// #include <stdlib.h>
// void __attribute__((noinline)) call_free(void (*f)(void *), char *p) { f(p); }
import "C"
import "fmt"

func main() {
        p := C.CString("test")
        fmt.Printf("p: %#v\n", p)
        C.call_free((*[0]byte)(C.free), p)
}

appears to work as expected:

% ltrace -e free ./main 2>&1|grep -A1 p:      
p: (*main._Ctype_char)(0xef4930)
main->free(0xef4930)                             = <void>
%

I can reproduce this doing

gert@debian:~/go/src/crawshaw.io/sqlite:master$ go test -v
# crawshaw.io/sqlite
cgo-generated-wrappers:7:13: warning: built-in function ‘free’ declared as non-function

@yath This occurs because you are referencing the free built-in as a variable. cgo creates forward declarations of all of the C variables you reference. In this case, it generates this code:

extern char free[];
void *_cgohack_free = free;

The extern declaration of free is what the compiler is (correctly) complaining about.

According to https://golang.org/cmd/cgo/#hdr-Go_references_to_C (you have to scroll down a bit), direct references to C function pointers are not supported. The document provides an example of how to work around this limitation in a non-trivial example.

Hi @qbradq,

According to https://golang.org/cmd/cgo/#hdr-Go_references_to_C (you have to scroll down a bit), direct references to C function pointers are not supported. The document provides an example of how to work around this limitation in a non-trivial example.

Sorry, I’m unable to find what you are referring to. The only mention of function pointers in the link you’ve provided is “Calling C function pointers is currently not supported”, but I’m not calling a function pointer, I’m just passing it to a different function. I can’t find anything about free (the only symbol that exposes this behavior) being special either.

What am I missing?

Note that that warning is coming from the C compiler. It's not coming from any Go tool. It is the C compiler that considers free to be a built-in function.

@yath I pointed out the documentation because I thought it might provide you with a solution to the real-world problem behind this ticket. I assumed there was a real-world problem behind the trivialized example given.

@qbradq, the example you are referring to is the one following “Calling C function pointers is currently not supported, however you can declare Go variables which hold C function pointers and pass them back and forth between Go and C. C code may call function pointers received from Go. For example:”?

If so, then that’s exactly what I’m doing here, except that C.fortytwo is called C.free in my case. The real-world code is calling tvb_set_free_sb and I’m working around the warning by having a void my_free(void *p) { free(p); } that I’m passing instead.

If you are referring to a different example, please provide a more specific link.

@yath This is the work-around I was suggesting. Maybe we could add an example to the documentation about how to work around C built-in symbols specifically.

I am not sure a compile-time check would be appropriate as you can never be 100% sure what a C compiler will complain about. But one can be added for the symbols in a specific C standard. I'm just not sure what the Go team's policy is on how compatible they want cgo to be with strange and unusual compilers :)

As I wrote initially, this is only happening with free, not with getenv for example. Both are defined in stdlib.h, so I’d expect the same amount of built-in-ness from both symbols, but free is somehow special.

I’m not saying that what I’m doing (passing C.free as a value) is necessarily sensible. I just don’t see where the documentation disagrees, and the fact that it does actually work and no warning is produced with a different symbol suggests that I don’t actually have to wrap every C library function with my own one.

Unfortunately this is going to be one of those, "Your mileage may vary" kind of things.

Do you think adding the following to the Cgo documentation would have helped you?

Cgo may generate code that produces warnings depending on the target C compiler. For example:

package main

// #include <stdlib.h>
import "C"
import "fmt"

func main() {
        fmt.Printf("%#v\n", C.free)
}

Gives the warning built-in function ‘free’ declared as non-function on many systems.

@yath free is special because your C compiler considers it to be special.

It may be possible to work around this problem by having cgo pass -fno-builtin to the relevant invocation of the C compiler. I'm not sure. But I would recommend that if someone wants to look into fixing this.

If -fno-builtin does get added to cgo build flags it seems like there also needs to be a way to explicitly disable the option. Depending on compiler and code it may have an impact on performance of the compiled program.

I think that it would only be needed when invoking the C compiler to determine the types of the functions, I don't think it would be needed for the final build.