Commit 94f44dd
committed
[meta.const.eval] Use
It is unclear whether the reading an inactive `char` variant member can
be well-defined. General rules for out-of-lifetime objects disallows
this, but [basic.lval]/11 arguably allows reading the whole union via
such a `char` glvalue. In any case, it seems better to use some more
uncontroversial way to read the value representation of `OptBool` in the
example during runtime.
[basic.fundamental]/10 requires `bool` to have the same object
representation, value representation, and alignment requirements as an
implementation-defined unsigned integer type. Presumably, the example
essentially expected such an underlying-like type to be `unsigned char`.
Since `unsigned char` can't have padding bits, it would be sufficient to
infer that `bool` can't have padding bits either on common
implementations. As a result, `bit_cast` to `char` or `unsigned char`
can work.
This PR clarifies the assumptions for `bool` in comments and switch to
use `bit_cast` to avoid arguable UB.bit_cast in the example to avoid UB1 parent 8db8628 commit 94f44dd
1 file changed
Lines changed: 5 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2867 | 2867 | | |
2868 | 2868 | | |
2869 | 2869 | | |
2870 | | - | |
2871 | | - | |
| 2870 | + | |
| 2871 | + | |
| 2872 | + | |
2872 | 2873 | | |
2873 | | - | |
| 2874 | + | |
2874 | 2875 | | |
2875 | 2876 | | |
2876 | 2877 | | |
2877 | 2878 | | |
2878 | 2879 | | |
2879 | 2880 | | |
2880 | 2881 | | |
2881 | | - | |
| 2882 | + | |
2882 | 2883 | | |
2883 | 2884 | | |
2884 | 2885 | | |
| |||
0 commit comments