Date: Wed, 1 Mar 2023 13:41:09 -0600
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
>
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
>
Received on 2023-03-01 19:41:22