August 02, 2012 Re: Why must bitfields sum to a multiple of a byte? | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | On 8/2/12 9:48 AM, monarch_dodra wrote:
> On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu wrote:
>> On 8/2/12 5:26 AM, monarch_dodra wrote:
>>> One of the *big* reasons I'm against having a hand chosen padding, is
>>> that the implementation *should* be able to find out what the most
>>> efficient padding is on the current machine (could be 32 on some, could
>>> be 64 on some)
>>
>> In my neck of the woods they call that "non-portability".
>>
>> If your code is dependent on the machine's characteristics you use
>> version() and whatnot.
>
> Well, isn't that the entire point: Making your code NOT dependent on the
> machine's characteristics?
>
> By forcing the developer to chose the bitfield size (32 or 64), you ARE
> forcing him to make a choice dependent on the machine's characteristics.
I think that's backwards.
Andrei
|
August 02, 2012 Re: Why must bitfields sum to a multiple of a byte? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 2 August 2012 at 14:52:58 UTC, Andrei Alexandrescu wrote: > On 8/2/12 9:48 AM, monarch_dodra wrote: >> By forcing the developer to chose the bitfield size (32 or 64), you ARE forcing him to make a choice dependent on the machine's characteristics. > > I think that's backwards. I think specifying bitfields, you're already going really low level; meaning you need explicit and full control. As for portability, if the size is specified, it comes down to endinness or order of the fields. Zlib header: http://tools.ietf.org/html/rfc1950 A zlib stream has the following structure: CMF, FLaG CMF: bits 0 to 3 CM Compression method bits 4 to 7 CINFO Compression info FLaG: bits 0 to 4 FCHECK (check bits for CMF and FLG) bit 5 FDICT (preset dictionary) bits 6 to 7 FLEVEL (compression level) This easily becomes: //assumes small-endian mixin(bitfields( ubyte, "CM", 4, ubyte, "CINFO", 4, ubyte, "FCHECK", 5, ubyte, "FDICT", 1, ubyte, "FLEVEL", 2)); //should be exactly 16 bits Now if a typo was done (wrong number of bits) or endianness is questionable, this becomes completely different as the fields could be as much as 3-7 bytes off (24 bits, or worse if it assumes 64bits, 56 bits off), or cover a much larger area than it should for the bits. This is unacceptable, especially if you need to get low level with the code. |
Copyright © 1999-2021 by the D Language Foundation