I am working on some C/Go interop code that includes this horror on the
C side (TYPE_BITS is 5 and NAMED_BITS is 16):
```
struct sxpinfo_struct {
SEXPTYPE type : TYPE_BITS;
/* ==> (FUNSXP == 99) %% 2^5 == 3 == CLOSXP
* -> warning: `type' is narrower than values
* of its type
* when SEXPTYPE was an enum */
unsigned int scalar: 1;
unsigned int obj : 1;
unsigned int alt : 1;
unsigned int gp : 16;
unsigned int mark : 1;
unsigned int debug : 1;
unsigned int trace : 1; /* functions and memory tracing */
unsigned int spare : 1; /* used on closures and when REFCNT is defined */
unsigned int gcgen : 1; /* old generation number */
unsigned int gccls : 3; /* node class */
unsigned int named : NAMED_BITS;
unsigned int extra : 32 - NAMED_BITS; /* used for immediate bindings */
}; /* Tot: 64 */
```
This gets converted to this Go struct:
```
type sxpinfo struct {
Gp uint16
Pad_cgo_0 [2]byte
Named uint16
Pad_cgo_1 [2]byte
}
```
I don't expect that Cgo will cope with the bitfields, but I am
surprised that it makes any effort at all beyond getting to alignment.
In particular the Go sxpinfo gives misleading field, Gp that although
the correct size, is not aligned at all with the bits in the C gp field
(one byte too far forward).
Is this behaviour expected? Would it not be more sensible to do with
bitfields what Cgo does with unions, and just give back a struct {
[8]byte }?
The second question is whether `#cgo pkg-config:` is expected to work
with -I flags?
I can generate the Go definitions with
```
go tool cgo -godefs -- $(pkg-config --cflags libR) generate.go
```
but including `#cgo pkg-config: R` or `#cgo pkg-config: libR` fails to
find the R headers.
thanks
Dan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/11d52d7756bdd1efb08d4d55b0a8c32939769d69.camel%40kortschak.io.
