This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Help with bit-field semantics in C and C++
- From: "Dave Korn" <dk at artimi dot com>
- To: "'Mark Mitchell'" <mark at codesourcery dot com>,"'Roger Sayle'" <roger at eyesopen dot com>
- Cc: "'Joe Buck'" <Joe dot Buck at synopsys dot com>,<gcc at gcc dot gnu dot org>
- Date: Tue, 24 Aug 2004 19:05:18 +0100
- Subject: RE: Help with bit-field semantics in C and C++
> -----Original Message-----
> From: gcc-owner On Behalf Of Mark Mitchell
> Sent: 24 August 2004 18:55
> To: Roger Sayle
> >The problem here is that a C++ enum can hold values outside the range
> >of it's type.
> >
> >enum E { zero = 0x00, one = 0x01 };
> >
> >void test(int n)
> >{
> > enum E x;
> >
> > x = (E)n;
> > switch (x)
> > {
> > case zero: foo(); break;
> > case one: bar(); break;
> > }
> >}
> >
> >int main()
> >{
> > test(255);
> > return 0;
> >}
> What's unspecified is what happens when you convert 255 to E.
Can't we determine by analogy to what happens when you cast 65535 to
short? IOW, isn't this just the same as any other cast of an out-of-range
value to a smaller size?
> We can specify that by saying that the value you get is the
> same as if
> you convert 255 to the underlying integer type of E. I don't
> think that
> the standard is saying, or means to say, that the compiler
> must actually
> bring the value into the allowed range of E.
What's wrong with saying "Under K'n'R C++, we would have used a
signedness-preserving truncation, but since we're ISO these days, we should
try and use a value-preserving truncation", which amounts to just a
truncation, so you truncate it down to one bit?
As a side issue, is enum signed or unsigned? I've always had a bit of a
problem conceptualising what values a 1-bit wide signed bitfield can take.
(Perhaps they should be regarded as plus and minus zero....)
[replying to Roger's last post]
> To paraphrase Mike Stump, "undefined" allows us to "rm -rf ~/" or
> core dump, I'm not sure if "unspecified" also allows us to seg fault
> in the case above?
I think the intent of "unspecified" is that the compiler is free to pick
and choose between two (or more) ambiguous interpretations of the standard
(so in the 1-bit-wide signed case, it could validly treat the possible
values as "0 or -1", or as "0 or +1", but not as "9999e3.3925483 or format
the HD".....
cheers,
DaveK
--
Can't think of a witty .sigline today....