C bitfields guarantees

[Timon Gehr]

On 7/10/24 09:55, Daniel N wrote:
> On Wednesday, 10 July 2024 at 07:43:40 UTC, Daniel N wrote:
>> On Wednesday, 10 July 2024 at 07:09:10 UTC, Walter Bright wrote:
>>> I had written a detailed reply, but realized you and I were simply 
>>> running around in the same circle saying the same things.
>>
>> Maybe some input from 3rd party could help?
>>
>> I use bitfields daily and never had any issues. What I do is to always 
>> use fix size types and then simply take all freedom away from the 
>> compiler.
>>
>> uint32_t a;
>> uint32_t  :32; // Forced padding
>> uint64_t b:10;
>> uint64_t c:10;
>> uint64_t  :44; // Forced padding
>> uint32_t d;
>>
>> I guess one can use 0 size bitfields also but I usually prefer to 
>> visualize how much padding remains for potential future use.
> 
> PS To avoid relying on convention, you could make an incomplete bitfield 
> a compilation error in D, then D bitfields would have C layout *AND* be 
> deterministic.
> 

Yes, something like that I think would be great, but I think Walter has 
a point that there should still be a way to match C bitfields even if 
the original author was less competent than you w.r.t. bitfield layout. 
Hence the proposal that anything goes if there is an `extern(C)` 
annotation, but for `extern(D)` bitfields, something like your approach 
would be enforced by the compiler.