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@lists.isocpp.org> 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@googlemail.com>
Sent: Wednesday, March 1, 2023 11:41 AM
To: std-discussion@lists.isocpp.org
Cc: Daniel Jennings <danielj@valvesoftware.com>
Subject: Re: [std-discussion] possible bit-field prvalue inconsistency

 

This is CWG 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion


--
Brian Bi