[expr.ass]/4:

When the left operand of an assignment operator is a bit-field that
cannot represent the value of the expression, the resulting value of
the bit-field is implementation-defined.

I haven't checked if we say anything about what happens when you
initialize a bit-field in this scenario, but the intent seems clear to
me and it isn't undefined.

On Fri, Feb 5, 2021 at 6:36 AM Peter Sommerlad (C++) via Core
<core_at_[hidden]> wrote:
>
> Hi
>
> while discussing MISRA C++ rules wrt bit fields we came across the
> following (slightly changed in C++20) sentence [class.bit] p.4:
>
> "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 (9.7.1), the original value and the value of the
> bit-field compare equal."
>
> This silently introduces UB, if the bit field is narrower as the
> underlying type.
>
> For an enumeration type with a specified underlying type that by
> definition can represent all of its values, does that mean a bit field
> must not be shorter than the underlying type to make it useful. Or does
> it mean, only the named enumerators can be stored to be no UB.
>
> struct{
> std::byte a:4;
> };
>
> can I ever access a and compare it with std::byte{0} ?
>
> Wouldn't it be useful to allow shorter bit fields for enumeration types
> and allow values that fit to be taken out of the bitfield?
>
> Regards
> Peter.
>
> --
> Peter Sommerlad
>
> Better Software: Consulting, Training, Reviews
> Modern, Safe & Agile C++
>
> peter.cpp_at_[hidden]
> +41 79 432 23 32
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2021/02/10474.php