Under which conditions does this fail to build? It's compiling perfectly fine with gcc both on my local box and the CI. Removing the names will break the code-generation of various bindings -- that's why the structs are named in the first place.

Under which conditions does this fail to build? It's compiling perfectly fine with gcc both on my local box and the CI. Removing the names will break the code-generation of various bindings -- that's why the structs are named in the first place.

Are you building it as C11? The issue is including it from a cpp compilation unit. You'll run into
error: ‘struct ZydisDecodedOperand_::<unnamed union>::ZydisDecodedOperandReg_’ invalid; an anonymous union may only have public non-static data members [-fpermissive]

I can keep the struct names but that would require to move them out of the union.

Ah. Yeah, we switched to C11 to permit anonymous unions. Looks like this is an incompatibility between C++ and C11 then, meh. I think we might have to keep the structs named, but move them out of the nesting then instead of removing the names.

Also you mentioned of possibly breaking bindings, how do you bind a type that comes from an anonymous struct/union, is it in C11 accessible from the global scope? I'm not that good with C but I would imagine the type can't be accessed, at least not in Cpp.

I don't think it's possible in C11 either, but bindgens often essentially flatten nested types into global scope, so it works there. If the structs are unnamed, they'll essentially get something like a SHA1 hash as their name.

Thinking about it again, however, I remembered that we actually stopped using bindgens for the languages where it mattered, switching to hand-crafted struct types instead. Having these fields named thus doesn't actually matter too much anymore. While I do like having them named, I feel that unnesting them kind of makes discoverability of the struct a lot worse -- you have to follow all the "links" to find the fields you're interested in, so I guess your proposed solution here is preferable.

I'm glad you commented before I pushed onto this branch, the alternative would be: https://github.com/ZehMatt/zydis/tree/fix-anonymous-types-2

@athre0z @ZehMatt Just found some minutes to check this. I'd highly prefer option 2 just to be on the safe side. I remember having some problems when working on the C# bindings. If you are fine as well @athre0z, maybe @ZehMatt you can create a PR for your other solution instead?

@athre0z @ZehMatt Just found some minutes to check this. I'd highly prefer option 2 just to be on the safe side. I remember having some problems when working on the C# bindings. If you are fine as well @athre0z, maybe @ZehMatt you can create a PR for your other solution instead?

I can either open a new PR or push it onto this one, as you wish.

@ZehMatt Sure, pushing it to this one is even better, thanks! Let's just wait for @athre0z to agree.

Hmm, yeah, it's fine with me. I feel like the struct is easier to navigate when nested as-is, but if there are still bindings that depend on this, let's do it as suggested. I think it will also result in better documentation in doxygen, since it otherwise also generates hashed struct names.

Alright pushed the other branch onto this one, the CI unfortunately won't run since this is my first PR.

Thanks! I started the CI.