Velocity Reviews > _Bool bitfields and cast / assignment

# _Bool bitfields and cast / assignment

Philipp Klaus Krause
Guest
Posts: n/a

 06-14-2010
Verse 1407: "A bit-field is interpreted as a signed or unsigned integer
type consisting of the specified number of bits."

Does this mean that when assigning a value to a _Bool bitfield of width
1 it is casted as when assigning to an unsigned int bitfield of width 1,
e.g. 2 is converted to 0 (instead of to 1 as when assinging to an
ordinary, non-bitfield _Bool)? If so what's the advantage of having
_Bool bitfields over unsigned int bitfields?

Philipp

Keith Thompson
Guest
Posts: n/a

 06-14-2010
Philipp Klaus Krause <(E-Mail Removed)> writes:
> Verse 1407: "A bit-field is interpreted as a signed or unsigned integer
> type consisting of the specified number of bits."

"Verse 1407"? That's 6.7.2.1p9 in the C99 standard.

> Does this mean that when assigning a value to a _Bool bitfield of width
> 1 it is casted as when assigning to an unsigned int bitfield of width 1,
> e.g. 2 is converted to 0 (instead of to 1 as when assinging to an
> ordinary, non-bitfield _Bool)? If so what's the advantage of having
> _Bool bitfields over unsigned int bitfields?

_Bool is already an unsigned integer type (6.2.5p6), so the quoted
statement shouldn't affect the behavior, which is goverened by
6.2.1.2p1:

When any scalar value is converted to _Bool, the result is 0
if the value compares equal to 0; otherwise, the result is 1.

But then I don't know why the second sentence of 6.7.2.1p9 is needed:

If the value 0 or 1 is stored into a nonzero-width bit-field
of type _Bool, the value of the bit-field shall compare equal
to the value stored.

Perhaps some strange things can happen with _Bool bitfields of
width > 1?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

lawrence.jones@siemens.com
Guest
Posts: n/a

 06-14-2010
Keith Thompson <(E-Mail Removed)> wrote:
>
> But then I don't know why the second sentence of 6.7.2.1p9 is needed:
>
> If the value 0 or 1 is stored into a nonzero-width bit-field
> of type _Bool, the value of the bit-field shall compare equal
> to the value stored.
>
> Perhaps some strange things can happen with _Bool bitfields of
> width > 1?

Well, if other values are stored into the bit-field, they *won't*
compare equal. Strange things can happen with _Bool bit-fields of width
> 1 if you set their value other than by assignment (e.g., memcpy).

--
Larry Jones

If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin

Peter Nilsson
Guest
Posts: n/a

 06-15-2010
(E-Mail Removed) wrote:
> Keith Thompson <(E-Mail Removed)> wrote:
> > But then I don't know why the second sentence of 6.7.2.1p9
> > is needed:
> >
> > * If the value 0 or 1 is stored into a nonzero-width bit-
> > field of type _Bool, the value of the bit-field shall
> > compare equal to the value stored.
> >
> > Perhaps some strange things can happen with _Bool bitfields
> > of width > 1?

>
> Well, if other values are stored into the bit-field, they
> *won't* compare equal.

But they should compare equal to the value converted to _Bool.

>*Strange things can happen with _Bool bit-fields of width> 1
> if you set their value other than by assignment (e.g.,
> memcpy).

Isn't this undefined behaviour because _Bool can have trap
representations?

--
Peter

lawrence.jones@siemens.com
Guest
Posts: n/a

 06-15-2010
Peter Nilsson <(E-Mail Removed)> wrote [quoting me]:
>
> > Strange things can happen with _Bool bit-fields of width> 1
> > if you set their value other than by assignment (e.g.,
> > memcpy).

>
> Isn't this undefined behaviour because _Bool can have trap
> representations?

It's only undefined behavior if _Bool actually does have trap
representations, you manage to create one, and you access it as
a _Bool rather than as bytes.
--
Larry Jones

That gives me a FABULOUS idea. -- Calvin

Tim Rentsch
Guest
Posts: n/a

 06-20-2010
(E-Mail Removed) writes:

> Peter Nilsson <(E-Mail Removed)> wrote [quoting me]:
>>
>> > Strange things can happen with _Bool bit-fields of width> 1
>> > if you set their value other than by assignment (e.g.,
>> > memcpy).

>>
>> Isn't this undefined behaviour because _Bool can have trap
>> representations?

>
> It's only undefined behavior if _Bool actually does have trap
> representations, you manage to create one, and you access it as
> a _Bool rather than as bytes.

ISTM that a _Bool bitfield (even assuming a length > 1 is allowed)
cannot have trap representations. Bitfields declared with a width
of N have N value bits (no padding bits), and _Bool being an
unsigned type is covered by 6.2.6.1p3 and 6.2.6.2p1:

Values stored in unsigned bit-fields and objects of type
'unsigned char' shall be represented using a pure binary
notation.

For unsigned integer types other than 'unsigned char', the
bits of the object representation shall be divided into two
groups: value bits and padding bits (there need not be any
of the latter. If there are N value bits, each bit shall
represent a different power of 2 between 1 and 2N-1, so that
objects of that type shall be capable of representing values
from 0 to 2**N-1 using a pure binary representation; this
shall be known as the value representation.

(The phrase 'unsigned char' is quoted to indicate it being in
the alternate (program) font; all other text is in a regular
font.)

So, even though a _Bool can have trap representations, I don't
think a _Bool bitfield can have trap representations.