Beej Jorgensen <b...@beej.us> writes:Padding is not permitted, at least not "in general". Consecutive
> James Dow Allen <jdallen2...@yahoo.com> wrote:
>>Note that OP's example does *not* have fields spanning an 8-bit
> This is a keen observation that I missed; nevertheless, with the
fields must be packed into the same storage unit and the
implementation must document the order in which this happens. This is
why James' observation is a good one. If you are writing
non-portable code, you *can* rely on some properties of bit fields.
I agree that they are a potability nightmare, but that is not always
>>The standard excerpt quoted *might* even lead to a *proof* that at mostPadding of bit fields can only happen when the size is such that it
>>4 patterns are possible, but I'll leave that to the C lawyers.
> This would be an interesting thing to see. With the the amount of
does not fit in the space remaining in the current "unit". The
implementation must also document what happens in this case and there
are only two possibilities.
> And I don't have anything against non-portable code when you know whatNot likely. There would have to be some odd flag like
> you're getting into. (I've calculated the length of a function by
> subtracting function pointers--and I'm not even going to apologize!) But
> in this case, the struct layout in memory could change on the same
> platform with the same compiler just by changing the optimization
> flags... it seems like it's just asking for trouble--proper trouble--to
> code around it.
-use-optimal-9-bit-chars for this to occur and, if it does, the
implementation must document the new packing rules or it will not be
Bit fields have huge problems, but they have fewer problems than they
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.