On 29 May 2008 12:05:21 GMT, richard@cogsci.ed.ac.uk (Richard Tobin)
wrote:

>In article <ou1t34lri0bubitds89t7ki9bnek6bnj6i@4ax.com>,
>Barry Schwarz <schwarzb@dqel.com> wrote:
>
>>Yes, the footnote is for information only and your quote takes
>>precedence. But if the order of bit-fields within an allocation unit
>>is implementation defined it sure reduces the portability of any code
>>trying to match an externally imposed layout.
>
>"The order" means high-to-low or low-to-high; it doesn't permit
>shuffling them around.

Yes, I understand that. On my system there is a status word where one
8 bit byte contains four one byte flags (f1, f2, f3, f4) and a four
byte integer (i1), in that order from left to right. If my struct
contains
int f1 : 1;
int f2 : 1;
int f3 : 1;
int f4 : 1;
int i1 : 4;
I have no guarantee that i1 follows f4. The order of the bit-fields
could be i1, f4, f3, f2, f1. And if it compiles the way I want on
version 1 of compiler 1, I have no assurance it will on version 2 or
on compiler 2. If it doesn't I cannot upgrade or switch. In order to
be strictly conforming (and therefore maximally portable) I need to
replace the bit fields with an unsigned char and use the shift and/or
and operators to extract the fields of interest. All of which seems
to defeat the purpose encouraged in footnote 106.


Remove del for email