C++ Logo


Advanced search

Re: [SG12] [isocpp-core] New Issue?: [class.bit] p.4 - silent UB and necessary restriction?

From: Tim Song <t.canens.cpp_at_[hidden]>
Date: Fri, 5 Feb 2021 06:52:48 -0600

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

Received on 2021-02-05 06:53:26