Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.lang.c Subject: Re: type and size of bit-fields Message-ID: <11042@dog.ee.lbl.gov> Date: 17 Mar 91 22:01:26 GMT References: <12638@adobe.UUCP> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 29 X-Local-Date: Sun, 17 Mar 91 14:01:26 PST In article <12638@adobe.UUCP> taft@adobe.COM writes: >The ANSI C standard states: "A bit-field is interpreted as an integral type >consisting of the specified number of bits." Based on this, one might expect >foo to be treated as a 24-bit integer. That is, in this context, "int" means >"integral type", not "16-bit integer". >However, this interpretation may be contradicted by an earlier statement >that the width of a bit-field "shall not exceed the number of bits in an >ordinary object of compatible type." This statement is somewhat enigmatic, >since it depends on what you think is meant by "compatible type" in this >instance. There is no contraction here (just a bit of confusing language). What this means is that there are various ways to declare bitfields: int :; signed int :; and unsigned int :; where is `small enough'. The last two produce signed and unsigned values that are exactly bits long, while the first one produces either signed or unsigned, at the implemention's discretion. `Small enough' here means that the should be no larger than the number of bits in a `signed int' or `unsigned int', whichever is the `compatible type' (to use the phrase quoted above, and thus define it implicitly [I hope]). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov