Note that the intent of CWG 2485 was to clean up the wording and fix the
rules for promoting bit-fields of type char8_t, char16_t, char32_t, and
wchar_t. The tentatively ready resolution should not affect any other cases.

Assuming `int` is 32 bits, a bit-field of `uint64_t` with width 30 should
promote to `int`, and the proposed changes for 2485 shouldn't change
anything there.

On Wed, Mar 1, 2023 at 2:47 PM Daniel Jennings via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> Thank you! (And thank you Shafik)
>
>
>
> Glad to hear I wasn’t completely off-base here, I’ll follow along the
> progress of that CWG, much appreciated.
>
>
>
> *From:* Edward Catmur <ecatmur_at_[hidden]>
> *Sent:* Wednesday, March 1, 2023 11:41 AM
> *To:* std-discussion_at_[hidden]
> *Cc:* Daniel Jennings <danielj_at_[hidden]>
> *Subject:* Re: [std-discussion] possible bit-field prvalue inconsistency
>
>
>
> This is CWG 2485.
>
>
>
> Public link:
> https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2485
>
>
>
> This is in drafting an should be resolved relatively soon. I'll look at
> what the proposed wording would imply for the implementation divergence you
> observed.
>
>
>
> On Wed, 1 Mar 2023 at 13:35, Daniel Jennings via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
> Hello C++ standard discussion folks,
>
>
>
> I’ve run across what I believe to be an inconsistency in the C++ standard
> regarding bit-field prvalues, shown below. My references are from the N4917
> draft (but this language appears unchanged in recent years). If what I’ve
> identified is not an inconsistency then the current language possibly
> deserves an editorial tweak (though I recognize that’s a separate process
> for reporting/fixing those).
>
>
>
> Namely, 7.3.7.5 states:
>
> > A prvalue for an integral bit-field (11.4.10) can be converted to a
> prvalue of type int if int can represent all the values of the bit-field;
> otherwise, it can be converted to unsigned int if unsigned int can
> represent all the values of the bit-field. If the bit-field is larger yet,
> no integral promotion applies to it. If the bit-field has enumeration type,
> it is treated as any other value of that type for promotion purposes.
>
>
>
> This implies the existence of integral bit-field prvalues, but Note 7 in
> 7.2.1.6 states:
>
> > [Note 7 : There are no prvalue bit-fields; if a bit-field is converted
> to a prvalue (7.3.2), a prvalue of the type of the bit-field is created,
> which might then be promoted (7.3.7). — end note]
>
>
>
> Furthermore, “a prvalue of the type of the bit-field is created” might be
> underspecifying the type of the resulting prvalue. For example, with
> uint64_t my_bit_field : 30; should that result in a 30-bit unsigned integer
> type (which would be promoted to ‘int’) or should that result in a “normal”
> uint64_t type (which then wouldn’t be promoted, obviously).
>
>
>
> For context, the cause for my investigation here is the divergent behavior
> between GCC/Clang (which will promote the above my_bit_field to an ‘int’
> when used in a normal mathy expression) and MSVC (which will treat it as a
> uint64_t), so if there’s prior discussion on this subject (in any forum) a
> link would be much appreciated, as I’ve been unable to find discussion of
> this specific (or related) detail.
>
>
>
>
>
> Thank you,
>
>
>
> Daniel Jennings
>
> Valve Corporation
>
>
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
*Brian Bi*