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