On Tue, Sep 1, 2020 at 12:10 AM 'Dan Kortschak' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> 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.
This is a bug. Sent https://golang.org/cl/252378.
> 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.
I think that currently cgo -godefs ignores #cgo lines. This was
recently reported at https://golang.org/issue/41072.
Ian
--
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/CAOyqgcVAM2-%3DJjffe1qpznozeBXZHGf302d-fJ9wE90ADUBWLw%40mail.gmail.com.
