sizeof suggestion

[Tim Rentsch]

Can you cite the Standard section(s) supporting your claim?

[that the width of a bit-field is part of its type]

6.7.2.1p10:

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

Yes, this is the main reference I was going to give (I mentioned
some others in another followup).

Question: given this statement and the definition of conversion
rank in 6.3.1.1p1, isn't the second item in the list in 6.3.1.1p2,
namely,

A bit-field of type _Bool, int, signed int, or unsigned int

redundant? Surely such a bit-field qualifies under the first
item in that list ("An object or expression with an integer type
whose integer conversion rank is less than or equal to the rank
of int and unsigned int"), doesn't it? It seems like the
statement about bit-fields might be better if put in a footnote.

 

[Peter Nilsson]

[that the width of a bit-field is part of its type]

6.7.2.1p10:

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

Then why does 6.2.7p1 say that for structs and unions to be
compatible, corresponding bitfields must have compatible
type *and* width?

Actually what it says is slightly different, namely, that
corresponding members are /declared/ with compatible types.
 The width of a bitfield serves to modify the /declared type/

Modify or qualify?

so as to define the /access type/ for the bitfield.
 Unfortunately the Standard is not always as clear as it could
be in distinguishing these two uses of "type" in relation to
bitfields.

Indeed. 6.7.2.1p4 says

A bit-field shall have a type that is a qualified or
unqualified version of _Bool, signed int, unsigned int,
or some other implementation-defined type.

If width is a part of the type, then declarations of bit-fields
are potential constraint violations in and of themselves!

Perhaps it's better to simply say bitfields do not have a type,
just a declared type and width. Personally, I'm happy calling
that declared type _the_ type since the standard uses that
terminology (even if it isn't the intent.)

I note that 6.3.1.1p2 talks about the 'original type'.
Considering...

struct foo { unsigned f : 6; } quux;

I would want quux.f to promote to an unsigned int if I used
it in an expression, e.g. bit manipulation.

 

[Tim Rentsch]

(e-mail address removed) wrote:
[that the width of a bit-field is part of its type]

6.7.2.1p10:

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

Then why does 6.2.7p1 say that for structs and unions to be
compatible, corresponding bitfields must have compatible
type *and* width?

Actually what it says is slightly different, namely, that
corresponding members are /declared/ with compatible types.
The width of a bitfield serves to modify the /declared type/

Modify or qualify?

Modify, because the result is a different type. It has a
different conversion rank, for example.

Indeed. 6.7.2.1p4 says

A bit-field shall have a type that is a qualified or
unqualified version of _Bool, signed int, unsigned int,
or some other implementation-defined type.

If width is a part of the type, then declarations of bit-fields
are potential constraint violations in and of themselves!

The paragraph is discussing declarations; clearly the type
being referred to is the type appearing in the declaration,
not the type of an expression accessing the bit-field, which
is described in 6.7.2.1p9.

Perhaps it's better to simply say bitfields do not have a type,
just a declared type and width. Personally, I'm happy calling
that declared type _the_ type since the standard uses that
terminology (even if it isn't the intent.)

Saying the declared type of a bit-field is the same as
the type of an expression that accesses a bit-field is
not consistent with 6.7.2.1p9. For example, storing an
out-of-range value into an unsigned integer type is
defined in terms of the maximum value /of the type/.
If the access type of a bit-field were the same as the
declared type of the bit-field, a wrong value could
be computed.

I note that 6.3.1.1p2 talks about the 'original type'.

Surely that phrase is intended to mean the type before promotion.

Considering...

struct foo { unsigned f : 6; } quux;

I would want quux.f to promote to an unsigned int if I used
it in an expression, e.g. bit manipulation.

Personally I think /any/ unsigned type (of smaller conversion rank
than 'unsigned int') should always be promoted to 'unsigned',
never to 'signed'. But that's not the decision that was made.

 

[Peter Nilsson]

Personally I think /any/ unsigned type (of smaller
conversion rank than 'unsigned int') should always be
promoted to 'unsigned', never to 'signed'.
 But that's not the decision that was made.

Indeed, even unsigned int is not precluded from promoting to
signed int if UINT_MAX == INT_MAX. I see that as a defect.

 

[Tim Rentsch]

Indeed, even unsigned int is not precluded from promoting to
signed int if UINT_MAX == INT_MAX. I see that as a defect.

Apparently this behavior is not what was intended, and just an
inadvertent mistake in the wording, introduced by changes for
TC3. Larry Jones gave a comment here (or c.s.c) along those
lines, maybe a few months ago. I don't have a reference handy.