type and size of bit-fields

[Checkpoint Technologies]

In article <1991Mar20.172906.3645 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <12638 at adobe.UUCP> taft at adobe.COM writes:
>>Now admittedly, nearly everything to do with bit-fields is implementation
>>dependent. On the other hand, it doesn't seem unreasonable to expect an
>>implementation to support bit-fields of any size up to and including the
>>largest integral type. Can anyone offer authoritative information...
>
>It's pretty much as you've stated.  The standard promises almost nothing
>about bitfields.  The degree of support for them is a "quality of
>implementation" issue.  One would hope for the property you request, but
>there is no guarantee of it.

Here's a kicker...  The best information I have right now is that SAS C
version 6.0 for the Amiga will use a different ordering and packing
scheme for bit fields than SAS C version 5.10.

Does it seem reasonable to anyone else that bit field ordering is *so*
indefinite that different versions of the compiler from the same vendor
for the same platform may do things differently?  This would seem to
prohibit writing records with bit fields to external storage, if there's
any chance that the program in question will ever be recompiled and then
asked to deal with the same records.

Perhaps the Standard has something to say in this regard?
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                ckp at grebyn.com      \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/