Panic in CGO

[Graham Miller]

I noticed that CGO panics when it encounters a C struct with only bit-sized fields in it.

I think it's related to this issue and this patch:

https://code.google.com/p/go/issues/detail?id=4114
https://code.google.com/p/go/source/detail?r=24d74bd32d81

It's not clear to me that the patch will fix this though.  Can someone who has tip built try "go run foo.go" where foo.go is:

http://play.golang.org/p/F0NcH4ucmS

I think it's an alignment issue, because if you add a "char c" field to the "foo" type in this code, the issue goes away.

graham

[minux]

cgo won't support bitfields types as Go doesn't support them;
although the panic is undesirable, it's not a major problem as cgo
don't support that program anyway.

on tip, cmd/cgo still panics:
# command-line-arguments
panic: runtime error: integer divide by zero
[signal 0x8 code=0x1 addr=0x42210b pc=0x42210b]

goroutine 1 [running]:
main.(*Package).structType(0xc20007b820, 0xc200099380, 0xc200087e40,
0xc, 0x6bad01, ...)
/home/minux/go/go2.hg/src/cmd/cgo/out.go:249 +0x17b
main.(*Package).writeOutputFunc(0xc20007b820, 0xc2000ea540, 0xc200099380)
/home/minux/go/go2.hg/src/cmd/cgo/out.go:473 +0x202
main.(*Package).writeOutput(0xc20007b820, 0xc200099000, 0x7fff73a9a0a0, 0xb)
/home/minux/go/go2.hg/src/cmd/cgo/out.go:451 +0x7e2
main.main()
/home/minux/go/go2.hg/src/cmd/cgo/main.go:270 +0xe6c

[Graham Miller]

It seems that you're overloading the term "doesn't support" to mean both "cannot access (the data)" and "blows up in your face if you even come near them". Are both of those intended behaviors?  If so, might I suggest that a bit of work is warranted to avoid the crash in the face of structs with bit fields?

graham

[minux]

On Tue, Apr 9, 2013 at 4:12 AM, Graham Miller <graham...@gmail.com> wrote:
> It seems that you're overloading the term "doesn't support" to mean both
> "cannot access (the data)" and "blows up in your face if you even come near

i agree that cmd/cgo's error detection is not good as it should be.

> them". Are both of those intended behaviors? If so, might I suggest that a
> bit of work is warranted to avoid the crash in the face of structs with bit
> fields?

I mean the panic is undesirable, but as Go doesn't support bitfields, using
C structs containing bitfields in cmd/cgo is not valid.
If you don't use any C struct that contains bitfields, you will be fine.

feel free to file an issue for the cgo panicking at bitfields, but it will be of
low priority IMHO. (Of course, you are welcome to fix it :) )