Bitfields

[skaller]

I may have missed it but bit fields aren't handled, right?

So bitfields are actually easy to handle with

 (int * int * base) bitfield

where the two ints are the left shift count and the mask length and the base is the underlying integer. This put the onus on the programmer to calculate the offset for their platform.

[skaller]

Let me flesh that out .. the client has to first define an ordinary integer in a structure containing the bit fields, and give it a dummy name.

Then a bit field specification can be given for that field, giving the offset and length. So the "base" above actually has to be the "name" of the field, that specified the type already (and the structure it is a member of). Access is then by load shift mask. Writing is a bit tricker, load, mask, mask input, shift input, or, store. You would need on pair of routines for every base type (int, uint32, etc) which might be handled polymorphically.

I think the client programmer can write these routines anyhow. So maybe it isn't necessary in Ctypes after all.

[yallop]

Right: there's currently no support for bitfields (#226), but I think it'd be useful to have.

[skaller]

Yeah, its tricky for the programmer. I have fields like

uint32_t x:8, y:12, z:8,w:4;

where it's clear from context the 4 fields, adding to 32, are intended to be consecutive in a 32 bit word. But this is equivalent:

uint32_t x:8;
uint32_t y:12;
uint32_t z:8;
uint32_t w:4;

but doesn't present the same intent to my human brain. I don't see how the layout can be guessed by a machine.