You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[class.bit] p4 It is not clear whether a value of enumeration whose underlying type is fixed can be compared equally with the stored value in a bit-field
#5200
Open
xmh0511 opened this issue
Jan 12, 2022
· 0 comments
If a value of an enumeration type is stored into a bit-field of the same type and the width is large enough to hold all the values of that enumeration type ([dcl.enum]), the original value and the value of the bit-field compare equal.
Presumably, this provision should cover the complete cases of the enumeration type. Instead, The example that follows this provision only demonstrates the one whose underlying type is not fixed.
For the enumeration BOOL whose underlying type is not fixed, [dcl.enum] p8 indeed specifies the smallest width the bit-field that can hold all the values should be.
For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the underlying type. Otherwise, the values of the enumeration are the values representable by a hypothetical integer type with minimal width M such that all enumerators can be represented. The width of the smallest bit-field large enough to hold all the values of the enumeration type is M.
However, how about the enumeration type whose underlying type is fixed? Consider such two examples:
Clang has a warning report for this example
enum BOOL: int {
FALSE=0,
TRUE=1
};
structA{
BOOL b: 1;
};
intmain(){
A a;
a.b = TRUE;
}
Instead, this example seems to be ok without any warning information
The same point that these two examples both have is that the enumeration BOOL whose underlying type is fixed, the different point is that their underlying types have a different signedness.
Seems we lack to specify a case whether a value of an enumeration type whose underlying type is fixed stored into a bit-field with width N can be compared equally with the original value. Should we augment [class.bit] p4 to be that?
If a value of an enumeration type whose underlying type is fixed is stored into a bit-field with width N of the same type and the value would be representable in a hypothetical signed or unsigned integer type with width N and the same signedness as the underlying type of the enumeration, the original value and the value of the bit-field compare equal. If a value of an enumeration type whose underlying type is not fixed is stored into a bit-field with width N of the same type and the width N is large enough to hold all the values of that enumeration type ([dcl.enum]), the original value and the value of the bit-field compare equal.
The above augment seems to be more conform to what the implementations have done.
The text was updated successfully, but these errors were encountered:
xmh0511
changed the title
[class.bit] p4 It is not clear whether a value of enumeration whose underlying type is fixed can be compared equally with the stored value
[class.bit] p4 It is not clear whether a value of enumeration whose underlying type is fixed can be compared equally with the stored value in a bit-field
Jan 12, 2022
[class.bit] p4 states
Presumably, this provision should cover the complete cases of the enumeration type. Instead, The example that follows this provision only demonstrates the one whose underlying type is not fixed.
For the enumeration
BOOL
whose underlying type is not fixed, [dcl.enum] p8 indeed specifies the smallest width the bit-field that can hold all the values should be.However, how about the enumeration type whose underlying type is fixed? Consider such two examples:
The same point that these two examples both have is that the enumeration
BOOL
whose underlying type is fixed, the different point is that their underlying types have a different signedness.Seems we lack to specify a case whether a value of an enumeration type whose underlying type is fixed stored into a bit-field with width
N
can be compared equally with the original value. Should we augment [class.bit] p4 to be that?The above augment seems to be more conform to what the implementations have done.
The text was updated successfully, but these errors were encountered: