cmd/cgo: size of struct with 0 length trailing field has changed

[ebfe]

package main

import (
        "fmt"
        "unsafe"
)

/*
struct st {
        int a;
        char d[0];
};
*/
import "C"

func main() {
        var s C.struct_st
        fmt.Println(unsafe.Sizeof(s))
}

$ go version
go version devel +c1ccbab Wed Jul 29 21:44:27 2015 +0000 linux/amd64
$ go run t.go
8

With go 1.4

$ go version
go version go1.4.2 linux/amd64
$ go run t.go
4

Is this expected? This potentially breaks a lot of c-bindings.

[ebfe]

This behaviour was introduced with 6f07ac2

[ianlancetaylor]

Right, this doesn't have anything to do with cgo as such. It's a change in the way the Go compiler handles trailing zero length fields.

I think for clarity it would help to see an example of the kind of code that will break.

[ebfe]

I ran into something like this:

import (
        "fmt"
        "unsafe"
)

/*
struct msg_header {
        int flags;
        int len;
        char data[0];
};
*/
import "C"

func marshalMsg(payload []byte, flags int) []byte {
        var hdr C.struct_msg_header
        hdr.flags = C.int(flags)
        hdr.len = C.int(len(payload))
        msg := C.GoBytes(unsafe.Pointer(&hdr), C.int(unsafe.Sizeof(hdr)))
        return append(msg, payload...)
}
func main() {
        fmt.Printf("%x\n", marshalMsg([]byte("hello"), 0))
}

go tip: 00000000050000000000000068656c6c6f
go 1.4.2: 000000000500000068656c6c6f

[ianlancetaylor]

We can fix this by dropping the trailing zero byte field in the cgo translation, but that breaks code like that in issue #8428. You can fix your code by using C.sizeof_struct_msg_header, but I agree that it would be nice if your existing code continued to work.

I'm not seeing any good choices here.

[ebfe]

Yes, I already discovered C.sizeof_struct_.... though it doesn't seem to be documented anywhere (?).

C.sizeof_struct_a != unsafe.Sizeof(C.struct_a) is pretty surprising.

[ianlancetaylor]

I think there is definitely a bug, we just need to decide who to break.

[gopherbot]

CL https://golang.org/cl/12864 mentions this issue.

[gopherbot]

CL https://golang.org/cl/12866 mentions this issue.

[LK4D4]

@ianlancetaylor Could you help me? What is recommended way now to get those fields like char[0]?

[ianlancetaylor]

It depends on why you want to access the field.

If you want to take its address, you can write code like
(*ELEMENTTYPE)unsafe.Pointer(uintptr(unsafe.Pointer(p)) + unsafe.Sizeof(STRUCTYPE{}))

I agree that this is not ideal but I don't see how to avoid it.

[LK4D4]

@ianlancetaylor We had code which received such struct from C, struct looks like:

struct dm_deps {
    uint32_t count;
    uint32_t filler;
    uint64_t device[0];
};

Before in go we just had cool struct with field device, which was sorta slice, at least range worked with it, like for _, d := range deps.device. Now there is no field at all. So only way is to get pointer and cast it to slice, right?

[ianlancetaylor]

I'm not sure I understand. Given a C struct like the above, you used to get a Go struct with a zero-sized array (not a slice). Writing
for _, d := range deps.device
would give you a loop that would execute zero times. That doesn't seem useful.

You will now have to get a pointer, convert it to an array pointer, and slice the array to the desired length.

[tiborvass]

@ianlancetaylor maybe this could help

package main

/*
#include <inttypes.h>
struct dm_deps {
    uint32_t count;
    uint32_t filler;
    uint64_t device[0];
};
*/
import "C"
import "fmt"

func main() {
    deps := &C.struct_dm_deps{}
    fmt.Printf("%#v\n", deps)
    // go version go1.4.2 linux/amd64
    // &main._Ctype_struct_dm_deps{count:0x0, filler:0x0, device:[0]main._Ctype_uint64_t{}}

    // go version devel +d3ffc97 Wed Jul 29 23:50:20 2015 +0000 linux/amd64
    // &main._Ctype_struct_dm_deps{count:0x0, filler:0x0}
}

(courtesy of @vbatts)

[LK4D4]

@ianlancetaylor Yes, you're right I think, this code was weird. Thanks for answers!

[gopherbot]

CL https://golang.org/cl/18542 mentions this issue.