Comment 1:

$ cat test.go
package test
/*
struct A {
        unsigned long count;
        struct {
                long value;
        } data[15];
};
*/
import "C"
type A C.struct_A
$ go tool cgo -godefs test.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs test.go
package test
type A struct {
        Count   uint64
        Data    [15]_Ctype_struct___0
}
@Mortdeus, please provide minimal and standalone test cases (like above)
next time, thanks.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 2:

Is there a workaround for this? It's breaking a project of mine that worked in 1.1.2

Comment 3 by Mortdeus@gocos2d.org:

I just manually wrote the them in.

Comment 4 by Mortdeus@gocos2d.org:

I just manually wrote them in.
mortdeus/egles@201cb06#diff-1f1850a75cd762fd2b932808ece04736L238

Comment 5:

Labels changed: added go1.3maybe.

Comment 6:

Labels changed: added release-none, removed go1.3maybe.

Comment 7:

Labels changed: added repo-main.

Comment 8:

I think this is reasonably fixable.  We just need to change the handling of unnamed
dwarf.StructType's to directly return a struct definition rather than indirectly via a
dummy identifier and typedef.  E.g., with a minor change on top of my patch for issue
8441 (mostly to make sure assigning to t.Go after the recursive call to c.Struct() is
safe), I get:
$ go tool cgo -godefs issue5253.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs issue5253.go
package test
type A struct {
        Count   uint64
        Data    [15]struct {
                Value int64
        }
}
There's a possible issue if C code does something silly like "typedef struct { ... } X,
Y;" then C.X and C.Y would now become distinct types, whereas previously they would be
treated as aliases of type __1.  I don't think that's an issue in practice, but it's
probably solvable if needed.
There's also an exponential code size blow up from pathological inputs like:
/*
typedef struct foo {
        struct {
                struct {
                        struct {
                                int x;
                        } a, b;
                } a, b;
        } a, b;
} A, B;
*/
import "C"
but that could be fixed by making (*typeConv).Struct() smarter when consecutive fields
reference the same DWARF type.  Though again, I don't expect it to be an issue in
practice.

Comment 9:

I've put together https://golang.org/cl/122900043 to fix the issue as described
in the initial bug report here.  E.g., for the input provided by minux in #1, here's the
output from patched cgo:
<<<<
$ go tool cgo -godefs test.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs test.go
package test
type A struct {
        Count   uint64
        Data    [15]struct {
                Value int64
        }
}
>>>>
I'd appreciate if any users affected by this could test that this patch (applied to tip)
fixes their issues with cgo -godefs, or if there are more details to address.

This bug gets even worse when you have something like this using anonymous unions & structs:

struct A {
float size;
union {
  struct {
    float ascent;
    float vAscent:
    float descent;
    float vDescent;
  }
  struct {
    float ascentByOrientation[2];
    float descentByOrientation[2];
  }
};
float lineGap;
}

Is there any chance that CGO will support this?

This issue is specifically about -godefs, which is only used for very specific purposes. So far this deficiency hasn't seemed to be a problem for the limited ways in whch -godefs is used. I doubt there is any active work to address this. That said, patches would be welcome.

I've run into this while trying to fix github.com/gen2brain/malgo, which wraps Miniaudio, which has huge structs (600 or 1200 bytes in size) with many embedded anonymous structs. They broke at some point, and trying to figure out what fields are misaligned is not fun at all.
Why wasn't the above patch murged? It's been sitting there for seven years.

@mdempsky Do you want to revive https://golang.org/cl/122900043 ?

I'd love to see this fixed. https://utcc.utoronto.ca/%7Ecks/space/blog/programming/GoCGoCompatibleStructs mentions this issue, and has a not so great workaround.

Agreed, it would be great to see this finally fixed.