Date: Wed, 1 Mar 2023 19:46:56 +0000
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]<mailto: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]socpp.org<mailto:Std-Discussion_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
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]<mailto: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]socpp.org<mailto:Std-Discussion_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Received on 2023-03-01 19:46:59