There has got to be a better way to deal with bitfields in C

Brainstorming
,
1

I just encountered a problem involving this MacOS header file:

typedef struct {
	natural_t                     pad1;
	mach_msg_size_t               pad2;
	unsigned int                  pad3 : 24;
	mach_msg_descriptor_type_t    type : 8;
} mach_msg_type_descriptor_t;
xnu_static_assert_struct_size(mach_msg_type_descriptor_t, 12);

After translation, the code becomes:

// /home/cleong/.zvm/0.16.0/lib/libc/include/any-darwin-any/mach/message.h:296:32: warning: struct demoted to opaque type - has bitfield
pub const mach_msg_type_descriptor_t = opaque {};
comptime {
    if (!(@sizeOf(mach_msg_type_descriptor_t) == @as(c_ulong, 12))) @compileError("static assertion failed \"struct changed size unexpectedly\"");
}

So any file that happens to include this header is untranslatable. Demoting structs with bitfields to opaque is not a viable solution. It just breaks too much stuff.

2

tracking issue: https://codeberg.org/ziglang/translate-c/issues/179

it’s just unimplemented

3

Layout of bitfields in C is compiler-dependent, so there isn’t general solution.

You can probably simulate this manually using packed struct or bitset after decoding what exactly the C code actually expects.

4

C translation is given the target, which includes the ABI, which tells bitfield layout. So there is a solution that works perfectly fine.

Sorry, edited the post to be less harsh.

5

(post deleted by author)

6

Yeah, the tracking bug describes the general solution. Lots of research and testing because start of the art elsewhere appears to be buggy/inaccurate.

Meanwhile until that work happens, you’re left with doing it manually and ungloriously to get past it for your use case, or contributing the fix, which would be blogworthy reputation building :-).