Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types: support cgo semantics #23090

Open
hirochachacha opened this issue Dec 11, 2017 · 2 comments
Open

go/types: support cgo semantics #23090

hirochachacha opened this issue Dec 11, 2017 · 2 comments
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@hirochachacha
Copy link
Contributor

I was thinking about #975.
My idea is guessing argument types and making specialized wrappers.
For example,
We can convert following code

package main

// #include <stdio.h>
import "C"

func main() {
	C.printf(C.CString("hello: %d"), 10)
	C.fflush(C.stdout)
}

into

package main

// #include <stdio.h>
// int call_printf_with_int(const char* s, int i) {
//   return printf(s, i);
// }
import "C"

func main() {
	C.call_printf_with_int(C.CString("hello: %d"), 10)
	C.fflush(C.stdout)
}

I'd like to leave these translations to cgo.

To promote this idea, we have to make go/types understand some special cgo semantics.

  • all cgo objects are exportable even if the first letter is lower case (e.g. C.char, C.int, ...)
  • cgo functions behave like unsafe.Pointer in the expression context (e.g. var xxx unsafe.Pointer = C.puts)
  • cgo functions can return the optional error argument in the assignment context (e.g _, err := C.puts(C.CString("x"))

Is this acceptable?

FWIW, https://go-review.googlesource.com/c/go/+/83215 is the attempt.

@ianlancetaylor
Copy link
Contributor

CC @griesemer @mdempsky

@griesemer griesemer self-assigned this Dec 11, 2017
@griesemer griesemer added FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Dec 11, 2017
@griesemer griesemer added this to the Go1.11 milestone Dec 11, 2017
@griesemer griesemer added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Dec 11, 2017
@griesemer
Copy link
Contributor

Too late for 1.11.

@griesemer griesemer modified the milestones: Go1.11, Go1.12 May 1, 2018
@griesemer griesemer modified the milestones: Go1.12, Go1.13 Dec 11, 2018
@griesemer griesemer modified the milestones: Go1.13, Go1.14 May 6, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants