"Bit fields" summary (LONG)

[stassen at trwspp.UUCP]

[]

	I've had at least ten requests for summaries, so I decided to
post this.  The numbered items below are the commonts I have received,
shortened and collated.  Thanks to all who responded.

	field:  flagvariable.flagname = 1;

	int:	flagvariable |= FLAGNAME;

	(Pro int):

	(1) Bit fields are not portable due to big endian/little endian gap.
	(2) A common use for flags is for I/O control registers (see (1)),
	    where bit placement determines function.
	(3) Using fields, you can't access more than one field at a time,
	    whereas you could OR in two or more bits at once.
	(4) Fields are not necessarily faster (optimizer should produce same
	    code for both field and int method).
	(5) It is very difficult to clear all flags in a field at once.
	(6) There was never a standard for the bit ordering (see (1)).
	(7) Sign extension can cause problems when changing size.. is a
	    single bit 1 or -1 when turned on?  How about 2-bit fields?
	(8) Everybody uses the int method, and is used to seeing it.  It
	    is easier to read.
	(9) Some C implementations do not have bit fields at all (e.g. Aztec,
	    MicroWare C for Os9 [6809])
	(A) Some C implementations only allow (8*sizeof(int)-1) bits in a 
	    field per integer -- one less than there should be (E.g. lattice).
	(B) Some big C compilers (E.g. DEC and ISC) occasionally produce
	    incorrect code for some operations on bit fields.
	(C) Some bit field operations cause the Unix C compiler to generate
	    incorrect code; apparently one case will cause it to crash.
	(Note) B and C from a compiler-designer, bhorn @ cit-750
	(D) Some operations are not supported (like the address of a member)
	    for bit fields.
	(E) It is easier to teach beginning programmers not to use bit fields
	    at all than it is to get them to understand when they can or can't
	    use them.

	(Pro field):

	(1) Fields allow an arbitrarily large grouping of flags (not limited
	    to 32, or whatever your local integer has).
	(2) They might be more efficient at runtime, if compiler isn't very
	    good (for home computers and such).
	(Note) 1 and 2 seem to be exclusive.  Home non-optimizing compilers
	    usually do not allow flag structures larger than integers.
	(3) Bit fields are well suited to machine-dependent code (like 
	    certain device drivers)
	(4) They are especially good for assemblers where groups of bits
	    in the object code indicate operands or addressing modes.
	(5) Bit fields are useful for simulation of tagged architectures.
	(6) They are the only way to communicate with write-only hardware if
	    you do not have lots of faith in your optimizer.
	(7) Bit fields are useful for Data General OS requests.

	(Sample field use): see /usr/include/wait.h (4.1 or 4.2)

					-- Chris

	Thanks (for information) to:

Mark Swanson      (mas at teddy)		Tom Long           (toml at oliveb)
Don Steiny        (steiny at scc)		Greg Noel          (greg at sdcsvax)
Anne H. Anderson  (anne at bmcg)		?	           (kissell at flairvax)
John Nelson       (john at genrad)         R. Mark Chilenskas (rmc at teddy)
William P. Malloy (malloy at ittral)       Douglas J. Leavitt (djl at tropix)
Craig Partridge   (craig at bbncca)        Alan Silverstein   (ajs at hpfcla)
Joe Mueller       (joemu at tekecs)        Bob Larson         (BLarson at Usc-ecl)
Phillip Yoo       (yoo at bbng)		Jim Van Zandt      (jrv at Mitre-Bedford)
Jon Leech         (jpl284 at cit-vax)      Andy Freeman       (freeman at sumex-aim)
Bob Greenbank     (rob at moloch)          David Barto        (Barto at celerity)
Ron Natalie       (ron at bgl-tgr)		Brian D. Horn      (bhorn at cit-750)
Matthew Weinstein (matt at ucla-cs)	Duk Bekema         (duk at vu44)
?		  (dick at jtalk)		Roger Hayes	   (roger at arizona)
Jim Hogue	  (hogue at hsi)		Michael Meissner   (mrm at datagen)
Michael McIlrath  (mbm at mit-xx)		David J. Cardinal  (djc at sun)
Mike Williams     (mike at erix)		Joel Coltoff       (coltoff at burdvax)
Richard Matthews  (richard at UCLA-LOCUS)  Scott Orshan       (sdo at u1100a)
Kenj McDonnell    (kenj at moncskermit)    Daniel S. Cox      (danny at itm)
Michael Rourke    (michaelr at elecvax)    ?                  (injerry at qsi03)
Lee Naish         (lee at mulga)           Binayak Bannerjee  (bbannerje at sjuvax)
Efrem Lipkin	  (efrem at lbl-csam)	Henry Spencer      (henry at utzoo)
Alan Fargusson    (alan at drivax)		Andy Kegel         (agk at ihuxq)