cmd/cgo: provide a way to pass a Go string directly to C code

[gopherbot]

by [email protected]:

What steps will reproduce the problem?

I'm writing a wrapper for a C++ API that takes with std::string arguments.  In order to
interface with it via CGo, I call it through a shim API.

Ideally, I would like to build the std::string instances directly from the Go string in
the shim layer, but there doesn't seem to be a way to declare the shim function such
that it can take the Go string directly.

I can't use the GoString declaration in _cgo_export.h, and declaring the GoString struct
type myself generates an error (for good reason).

What is the expected output?

A way to declare my function so that it can accept a Go string directly.

What do you see instead?

There is no way to do the above, and I need to convert the string to a *C.char (which
causes an unneeded allocation and two extra Go->C transitions for the allocation and
release of the memory).


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

6g

Which operating system are you using?

Linux (amd64)

Which version are you using?  (run 'go version')

1.2

[rsc]

Comment 1:

You can certainly do unsafe things already to get at the string memory. If you must, do
that. I don't believe that we will support this more easily, because a C++ string is
mutable and a Go string is not.

Status changed to WorkingAsIntended.

[gopherbot]

Comment 2 by [email protected]:

I'm not after a way to alter the Go string.  I've worked with enough language bindings
to know not to screw around with the runtime like that.
Rather, if I'm going to have to make a copy of the string to call my API, it seems
wasteful to create an intermediate copy with C.GoString rather than just using the
original Go string as source for the copy.
Similarly, for API calls that can deal with constant string data plus a length, it'd be
nice to be able to do so without a copy.
If there are existing ways to handle this kind of thing, would it be possible to
document them?

[ianlancetaylor]

I think this is a reasonable thing to do. We should provide a way for the C code to get a pair of a const char * and length, to make it straightforward to pass a Go string to C code without a copy. Yes, they can break things horribly, but there are many ways to do that.

[rsc]

I agree this is reasonable, but it's too late in the cycle to do it now.

[gopherbot]

Change https://golang.org/cl/70890 mentions this issue: cmd/cgo: permit passing string and []byte directly between Go and C

[bcmills]

We should provide a way for the C code to get a pair of a const char * and length, to make it straightforward to pass a Go string to C code without a copy.

It occurs to me that the combination of runtime.KeepAlive and reflect.StringHeader already makes that possible today (provided that one is willing to ignore the “cannot be used safely or portably” caveat of reflect.StringHeader):

func asPtrAndLength(s string) (*C.char, int) {
	addr := &s
	hdr := (*reflect.StringHeader)(unsafe.Pointer(addr))

	p := (*C.char)(unsafe.Pointer(hdr.Data))
	n := hdr.Len

	// reflect.StringHeader stores the Data field as a uintptr, not a pointer,
	// so ensure that the string remains reachable until the uintptr is converted.
	runtime.KeepAlive(addr)

	return p, n
}