type and size of bit-fields

[Steve Summit]

In article <1991Mar20.224317.1265 at grebyn.com> ckp at grebyn.com (Checkpoint Technologies) writes:
>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.

This is why I (and many others) recommend *never* using "binary"
data files.

A couple of years ago, I made two mistakes: I disregarded my own
advice about binary data files, and I used a certain popular but
widely vilified processor having several architectural
peculiarities, including various "memory models," which end up
being highly visible at the source code level.

It happened that the structures I was writing out contained a few
pointer fields.  Of course, the pointer values were meaningless
when read back in (and the program took care of fixing them), but
arranging not to write them out at all would have meant writing
out the rest of the structure piecemeal, which would destroy the
whole point of these accursed "binary" files, namely that you can
read and write entire structures in one swell foop with fread and
fwrite.

Well, one day I had occasion to recompile the programs in
question using the "large memory model," in which pointers are 32
bits rather than 16.  Presto: all my old data files (and there
were hundreds of them, scattered all over the place) were
unreadable by new programs.  To this day I have to maintain
separate, "small model" versions of key programs (and several
large libraries) in order to deal with the older data files,
many of which are still around.

The moral: DON'T USE BINARY DATA FILES.  (You'll say, "but we
have to, for efficiency."  Sure, and go ahead, but don't come
crying to me :-) when you have problems -- and you will have
problems.)

>Perhaps the Standard has something to say in this regard?

It says (implicitly) "It's a quality of implementation issue."
I agree that the abovementioned change to the SAS compiler is
extremely low-quality: whether or not you're not using binary
data files, you'll have to recompile *all* of your object files
(and vendor-supplied libraries, assuming you have source for
them) if they deal with structures containing bitfields.

                                            Steve Summit
                                            scs at adam.mit.edu