Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bitfield types/sizes and the integer promotions

0 views
Skip to first unread message

Thomas David Rivers

unread,
Jun 5, 2009, 4:00:25 PM6/5/09
to

The C99 standard says (in the section on conversions):

If an int can represent all values of the original
type, the value is converted to an int; otherwise,
it is converted to an unsigned int.

The standard goes on to say in the structure-and-union-specifiers
section that the types allowed on bitfields are _Bool, signed int,
unsigned int, or some other implementation-defined type.

Now, let's consider this fragment (for the sake of
this discussion, lets assume a 32-bit 2's-complement machine):

struct s {
unsigned int bf:1;
};

func()
{
int i, j;
struct s s;

i = -1;
j = 0;
s.bf1 = 0;

if(i < j + s.bf1) {
...

In the expression "i < j + s.bf1", should
the comparison be evaluated as:

(unsigned int) < (unsigned int)

or as

(int) < (int)


Given the standard wording above, it's clear that
all of the _values_ of s.bf1 can be represented
as an (int) type. However, the type of the
bitfield does not seem to include its size.
The type of the bitfield is clearly (unsigned int)
and all of the values of (unsignd int) can't
be represented in (int).

Since C99 says "can represent all values of the original
type" - what's the correct interpretation here?

You can see in the fragment above, if the
integer promotions determine that the comparison
is to be evaluated with (unsigned int), you
get a different result than if it is evaluated
as (int). If it is (unsigned int), then
the comparison is the same as (0xffffffffU < 0),
if it is (int) then the comparison is ( -1 < 0 );
two different results.

I'm wondering if I've missed some other
clarifying clause in the standard that might
address this. Perhaps something that indicates
the size of the bitfield should be considered
as part of its type ?


- Thanks! -
- Dave Rivers -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

Thomas David Rivers

unread,
Jun 5, 2009, 4:47:57 PM6/5/09
to
Sorry to answer my own post, but further reading
from ANSI C99 6.7.2.1 says:

A bit-field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.

which kinda indicates that the size of the bitfield
should be considered when doing promotions.

Is that the consensus?

lawrenc...@siemens.com

unread,
Jun 5, 2009, 6:07:29 PM6/5/09
to
Thomas David Rivers <riv...@dignus.com> wrote:
>
> Given the standard wording above, it's clear that
> all of the _values_ of s.bf1 can be represented
> as an (int) type. However, the type of the
> bitfield does not seem to include its size.

No, see 6.7.2.1p9:

A bit-field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.

--
Larry Jones

That gives me a FABULOUS idea. -- Calvin

Tim Rentsch

unread,
Jun 6, 2009, 8:15:13 PM6/6/09
to
Thomas David Rivers <riv...@dignus.com> writes:

> Sorry to answer my own post, but further reading
> from ANSI C99 6.7.2.1 says:
>
> A bit-field is interpreted as a signed or unsigned integer type
> consisting of the specified number of bits.
>
> which kinda indicates that the size of the bitfield
> should be considered when doing promotions.
>
> Is that the consensus?

Yes. A bit-field x declared 'unsigned int x:3;' gets promoted to
(int), not (unsigned int), in arithmetic operations. It may
subsequently get converted to (unsigned int) to combine with
another (unsigned int) operand, but that's a separate step.

0 new messages