Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!jit345!diamond
From: diamond@jit345.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: type and size of bit-fields
Message-ID: <1991Mar18.041642.4194@tkou02.enet.dec.com>
Date: 18 Mar 91 04:16:42 GMT
References: <12638@adobe.UUCP> <1991Mar18.004505.2293@tkou02.enet.dec.com>
Sender: news@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 28

In article <1991Mar18.004505.2293@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>In article <12638@adobe.UUCP> taft@adobe.COM writes:
>
>>What should be the interpretation of the following bit-field appearing in a
>>struct?
>>  int foo: 24;
>>...
>>In light of this, a possible work-around comes to mind:
>>  long int foo: 24;
>>Unfortunately, this violates the ANSI C standard, which states: "A bit-field
>>may have type int, unsigned int, or signed int" -- omitting long types.
>
>According to the Dec. 1988 draft,
>>may have type int, unsigned int, or signed int" -- omitting long types.
>was really:
>SHALL have ....
>
>If this was changed in the final version, then we get to play more games
>with the semantics of English.  If it was not changed, then quite clearly
>you cannot declare any bitfield longer than an int (in a conforming program),
>besides being limited to the size of the type-specifiers if you specified any.
>--
>Norman Diamond       diamond@tkov50.enet.dec.com
>If this were the company's opinion, I wouldn't be allowed to post it.

--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.