Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Subject: Re: type and size of bit-fields
Message-ID: <1991Mar20.224317.1265@grebyn.com>
Organization: Grebyn Timesharing
References: <12638@adobe.UUCP> <1991Mar20.172906.3645@zoo.toronto.edu>
Date: Wed, 20 Mar 1991 22:43:17 GMT

In article <1991Mar20.172906.3645@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <12638@adobe.UUCP> taft@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@grebyn.com      \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/
