Re: [go-nuts] cgo godefs questions
On Tue, 2020-09-01 at 17:03 -0700, Ian Lance Taylor wrote: > > This is a bug. Sent https://golang.org/cl/252378. > > I think that currently cgo -godefs ignores #cgo lines. This was > recently reported at https://golang.org/issue/41072. > > Ian Thanks, Ian for both of those. 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/3b5245288718a4bf774cd842e558339398daeb54.camel%40kortschak.io.
Re: [go-nuts] cgo godefs questions
On Tue, Sep 1, 2020 at 12:10 AM 'Dan Kortschak' via golang-nuts
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 {
> Gpuint16
> 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.
[go-nuts] cgo godefs questions
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 {
Gpuint16
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.
