4 ms·

Getting C-compatible structs in Go with and for cgo

39 points by ash 11y ago

robmccoll 11y ago
I wish Go made more of an effort to be more easily C compatible instead of trying to continue breaking away from C.
- nulltype 11y ago
  What could they do to be more C compatible?
- zik 11y ago
  I think they're just trying to make the best language they can. Surely they shouldn't compromise that for C compatibility?
parennoob 11y ago
From the article: > (By the way, I do mean 'Sysinfo' here, not 'Cpu_sysinfo'. Cgo is smart enough to take that sort of commonly seen prefix off of struct field names. I don't know what its algorithm is for doing this, but it's at least useful.) Anyone know why cgo does this? This seems like an anti-feature to me – if I want fields with prefixes that are different from the C ones, at least make that a knob (and preferably one that isn't turned on by default).
bluejekyll 11y ago
This just makes the beauty of Rust so much more clear. Compatible C structs without going through this headache. It also points out another reason why Go is not a "systems" language.
- mahmud 11y ago
  You could do that in Common Lisp for about 3 decades now. I remember doing this 10 years ago, from the REPL no less. https://common-lisp.net/project/cffi/manual/html_node/defcstruct.html https://common-lisp.net/project/cffi/manual/html_node/defcst...
- pjmlp 11y ago
  I never understood why they didn't take the FFI route that Delphi, Pascal dialects, Modula-2, Modula-3, .NET, D, Ada, Rust and many other languages do, for describing bindings to other languages. When I asked about why going cgo instead, the general reaction was "go away we know better", as usual. EDIT: Typo (way => away)
laxk 11y ago
It is still useless for me if you have struct with 'packed' attribute ie: http://lxr.free-electrons.com/source/fs/btrfs/ctree.h#L220 http://lxr.free-electrons.com/source/fs/btrfs/ctree.h#L220 // +build ignore package tmp /* #include <btrfs/ctree.h> */ import "C" // 220 struct btrfs_disk_key { // 221 __le64 objectid; // 222 u8 type; // 223 __le64 offset; // 224 } __attribute__ ((__packed__)); type BtrfsDiskKey C.struct_btrfs_disk_key Output: $ go tool cgo -godefs test.go // Created by cgo -godefs - DO NOT EDIT // cgo -godefs test.go package tmp type BtrfsDiskKey struct { Objectid uint64 Type uint8 Pad_cgo_0 [8]byte } After all the experiments I created my own helper[1], which helps map C structure(even packed) to Go structure using reflect package. [1] https://github.com/plar/btrfs/blob/master/ioctl/mappings.go https://github.com/plar/btrfs/blob/master/ioctl/mappings.go
- _pmf_ 11y ago
  > It is still useless for me if you have struct with 'packed' attribute It's somewhat sad that LuaJIT (effectively a one man project) contains a FFI interface with a hand-crafted lexer and tokenizer that supports the packed attribute correctly.

39 points by ash 11y ago

robmccoll 11y ago

I wish Go made more of an effort to be more easily C compatible instead of trying to continue breaking away from C.

nulltype 11y ago
What could they do to be more C compatible?
zik 11y ago
I think they're just trying to make the best language they can. Surely they shouldn't compromise that for C compatibility?

parennoob 11y ago

From the article: > (By the way, I do mean 'Sysinfo' here, not 'Cpu_sysinfo'. Cgo is smart enough to take that sort of commonly seen prefix off of struct field names. I don't know what its algorithm is for doing this, but it's at least useful.) Anyone know why cgo does this? This seems like an anti-feature to me – if I want fields with prefixes that are different from the C ones, at least make that a knob (and preferably one that isn't turned on by default).

bluejekyll 11y ago

This just makes the beauty of Rust so much more clear. Compatible C structs without going through this headache. It also points out another reason why Go is not a "systems" language.

mahmud 11y ago
You could do that in Common Lisp for about 3 decades now. I remember doing this 10 years ago, from the REPL no less. https://common-lisp.net/project/cffi/manual/html_node/defcstruct.html https://common-lisp.net/project/cffi/manual/html_node/defcst...
pjmlp 11y ago
I never understood why they didn't take the FFI route that Delphi, Pascal dialects, Modula-2, Modula-3, .NET, D, Ada, Rust and many other languages do, for describing bindings to other languages. When I asked about why going cgo instead, the general reaction was "go away we know better", as usual. EDIT: Typo (way => away)

laxk 11y ago

It is still useless for me if you have struct with 'packed' attribute ie: http://lxr.free-electrons.com/source/fs/btrfs/ctree.h#L220 http://lxr.free-electrons.com/source/fs/btrfs/ctree.h#L220 // +build ignore package tmp /* #include <btrfs/ctree.h> */ import "C" // 220 struct btrfs_disk_key { // 221 __le64 objectid; // 222 u8 type; // 223 __le64 offset; // 224 } __attribute__ ((__packed__)); type BtrfsDiskKey C.struct_btrfs_disk_key Output: $ go tool cgo -godefs test.go // Created by cgo -godefs - DO NOT EDIT // cgo -godefs test.go package tmp type BtrfsDiskKey struct { Objectid uint64 Type uint8 Pad_cgo_0 [8]byte } After all the experiments I created my own helper[1], which helps map C structure(even packed) to Go structure using reflect package. [1] https://github.com/plar/btrfs/blob/master/ioctl/mappings.go https://github.com/plar/btrfs/blob/master/ioctl/mappings.go

_pmf_ 11y ago
> It is still useless for me if you have struct with 'packed' attribute It's somewhat sad that LuaJIT (effectively a one man project) contains a FFI interface with a hand-crafted lexer and tokenizer that supports the packed attribute correctly.