Repository navigation
CWG3225 [conv.integral] Conversion of bool to width-1 signed integer type #365
Description
Activity
I don't think there are any integer types with width 1; [implimits] doesn't allow that.
Reacted by A. JiangSorry, which part of [implimits] prohibits such a type? It isn't immediately obvious to me.
https://eel.is/c++draft/basic.fundamental#4.sentence-1
specifies the minimum width to be 8.Reacted by A. JiangI don't see a way to read that as applying to extended integer types.
An extended integer type is an integer type.
So it applies.
Unless you can point to where that restriction is lifted.Reacted by A. JiangSorry, which part of [implimits] prohibits such a type? It isn't immediately obvious to me.
Sorry, it's in [basic.fundamental], as @JohelEGP has pointed out.
I don't see a way to read that as applying to extended integer types.
https://eel.is/c++draft/basic.fundamental#4.sentence-1
applies to "signed integer type",
which is defined at https://eel.is/c++draft/basic.fundamental#def:type,signed_integer
and includes extended signed integer types.I think that sentence should read "standard signed integer type". Otherwise, we couldn't have extended integer types at all (because the referenced table is exhaustive).
[conv.rank] doesn't help either. Looks like we don't exclude "small" extended integer types. I wonder if we should.
A related question is whether an "int" bit-field of width 1 can faithfully store a "bool" value. [class.bit] p4 doesn't read to me like it could.
Isn't that because it falls out from other rules?
Initializing a non-boolbit-field from a value ofboolstores0or1.But a signed bit-field with width 1 can store the values 0 and -1 only. So, what do we do with the
bool1?Reacted by A. JiangAh, I see.
So if it doesn't fall out from other rules, it would be UB by omission.
Maybe you can tag someone who's trying to document or get rid of UB in the standard.I think this deserves a CWG issue now.
We now say "The width of each standard signed integer type shall not be less than the values specified in Table 14." in [basic.fundamental], so this no longer applies to extended integer types.
It would be possible for the implementation to provide an
_ExtInt(1)extended signed integer type with a single bit, so it's unclear whatstatic_cast<_ExtInt(1)>(true)does. P3666 would concretely introduce a_BitInt(1)type as well, and that's past EWG, but the defect is pre-existing.The C standard is also not super helpful here https://cstd.eisie.net/c2y.html#6.3.2.3p3
Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
true -> _BitInt(1)either gives an implementation-defined result or raises a signal, and C compilers don't support_BitInt(1)yet so we don't know yet how they'll deal with this case.In my opinion, this should be ill-formed in C++, which would keep the door open to future standardization that aligns with different behavior in C2y.
Reacted by A. JiangThe C standard is also not super helpful here https://cstd.eisie.net/c2y.html#6.3.2.3p3
Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
true -> _BitInt(1)either gives an implementation-defined result or raises a signal, and C compilers don't support_BitInt(1)yet so we don't know yet how they'll deal with this case.GCC documents what will happen here: https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
In my opinion, this should be ill-formed in C++, which would keep the door open to future standardization that aligns with different behavior in C2y.
bool to _BitInt(1) conversions would be ill-formed? That seems very arbitrary when any other integer type can be converted to _BitInt(1). Also I have created C Issue 1063 which discusses this so perhaps the wording can be changed.
- changed the title
[-][conv.integral] Conversion of bool to width-1 signed integer type[/-][+]CWG3225 [conv.integral] Conversion of bool to width-1 signed integer type[/+]on Aug 30, 2026
Full name of submitter: Janet Cobb
Reference (section label): [conv.integral]
Issue description:
A signed integer type of width 1 has possible values -1 to 0 per [basic.fundamental].
[conv.integral] states that:
Converting
trueto a width-1 signed integer type therefore should result in the value 1, which is not representable in the target type. This likely results in undefined behavior per [expr.pre]/4.Suggested resolution (explicitly define the behavior):
This would result in
falsebeing converted to0andtruebeing converted to-1.Alternative resolution (explicitly note the behavior is undefined):