Mattias Holm wrote:
>> Except that bitfields don't appear to be a widely used feature.
> 
> You clearly have not written systems code in Ada... :)
> 
> C-bitfields are problematic because the bit-ordering is implementation defined, GCC have the bits appear in the order of definition on big-endian machines and the reverse order on little endian machines. The appropriate way is to have them as the big-endian fields in GCC, this is also what most Ada-compilers seem to be doing.
> 
> They are incredibly useful for any systems and protocol programming, and this is why they are nice to have in a language like D.
> 
> Bitfields are not used in C because they are not platform neutral, a proper definition in D would mean that people would use them, at least in the mentioned domains.

Bitfields in Phobos are defined portably: always populated from lsb to msb, the total size must be 8, 16, 32, or 64, and there is no hidden padding (you obtain padding with anonymous fields).

Andrei

> Bitfields in Phobos are defined portably: always populated from lsb to msb, the total size must be 8, 16, 32, or 64, and there is no hidden padding (you obtain padding with anonymous fields).
> 
> Andrei

If this is the case, the bitfields are not portable and the behaviour is the same as for GCC, except it is reversed.

The order should be:

LSByte to MSByte on little endian machines
MSByte to LSByte on big endian machines


This means that bitfields are defined in human readable order with respect to the physical layout on the machine.

The point being:

struct {
  uint a:4;
  uint b:28;
}

should give a structure:
 _ _______
|.|.......|

where each dot represents 4 bits. And this structure should be identical if the data is moved between different systems, that is a TCP header definition mapping into a byte stream, should be identical on both PPC and x86. If the LSB to MSB ordering is used in phobos, then the bitfields are as useful as the GCC bitfields, i.e. not at all.


/Mattias

Mattias Holm wrote:
>> Bitfields in Phobos are defined portably: always populated from lsb to msb, the total size must be 8, 16, 32, or 64, and there is no hidden padding (you obtain padding with anonymous fields).
>>
>> Andrei
> 
> If this is the case, the bitfields are not portable and the behaviour is the same as for GCC, except it is reversed.
> 
> The order should be:
> 
> LSByte to MSByte on little endian machines
> MSByte to LSByte on big endian machines
> 
> 
> This means that bitfields are defined in human readable order with respect to the physical layout on the machine.
> 
> The point being:
> 
> struct {
>   uint a:4;
>   uint b:28;
> }
> 
> should give a structure:
>  _ _______
> |.|.......|
> 
> where each dot represents 4 bits. And this structure should be identical if the data is moved between different systems, that is a TCP header definition mapping into a byte stream, should be identical on both PPC and x86. If the LSB to MSB ordering is used in phobos, then the bitfields are as useful as the GCC bitfields, i.e. not at all.

Not at all is a tad extreme as I'm using them already. I see your point though. If you could submit a bug report, that would be great.


Andrei