Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.c
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Accessing bit fields of a structure
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ben Bacarisse  
View profile  
 More options Jun 15 2009, 1:26 pm
Newsgroups: comp.lang.c
From: Ben Bacarisse <ben.use...@bsb.me.uk>
Date: Mon, 15 Jun 2009 18:26:43 +0100
Local: Mon, Jun 15 2009 1:26 pm
Subject: Re: Accessing bit fields of a structure
Print | View thread | Show original | Report this message | Find messages by this author

Beej Jorgensen <b...@beej.us> writes:
> James Dow Allen  <jdallen2...@yahoo.com> wrote:
>>Note that OP's example does *not* have fields spanning an 8-bit
>>boundary,

> This is a keen observation that I missed; nevertheless, with the
> possibility of padding insertion and bit reversal, it's still going to
> be "interesting" to get the overlain struct to make sense in all
> cases.

Padding is not permitted, at least not "in general".  Consecutive
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 issue.

>>The standard excerpt quoted *might* even lead to a *proof* that at most
>>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
> padding between struct elements being variable, I would think it would
> be difficult to code for.

Padding of bit fields can only happen when the size is such that it
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.

<snip>

> And I don't have anything against non-portable code when you know what
> 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.

Not likely.  There would have to be some odd flag like
-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
conforming.

Bit fields have huge problems, but they have fewer problems than they
are often portrayed as having!

--
Ben.


 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google