Date: Tue, 21 Sep 2021 15:44:26 +0000
> I'm thinking specifically about floating point division by zero, which
> sometimes hits a hardware exception and sometimes produces
> floating-point infinity (when is_iec559 is true).
>
> As with other cases of undefined behavior, this is made testable by
> constexpr. Can an implementation say that a construct that is
> undefined in the C++ standard is defined in that implementation, and
> therefore accept it in constexpr?
For this case in particular, SG6 (or at least Lawrence) has in the past recommended against supporting it <https://wiki.edg.com/bin/view/Wg21issaquah2016/CoreWorkingGroup#Core_issue_2168_Narrowing_conver> <https://lists.isocpp.org/sci/2016/03/0000.php>.
More generally, I don't think it's conforming to "define undefined behavior" during constant evaluation, even though it obviously is so at runtime. Of course, you can always issue a diagnostic and accept the program anyway.
Davis
> sometimes hits a hardware exception and sometimes produces
> floating-point infinity (when is_iec559 is true).
>
> As with other cases of undefined behavior, this is made testable by
> constexpr. Can an implementation say that a construct that is
> undefined in the C++ standard is defined in that implementation, and
> therefore accept it in constexpr?
For this case in particular, SG6 (or at least Lawrence) has in the past recommended against supporting it <https://wiki.edg.com/bin/view/Wg21issaquah2016/CoreWorkingGroup#Core_issue_2168_Narrowing_conver> <https://lists.isocpp.org/sci/2016/03/0000.php>.
More generally, I don't think it's conforming to "define undefined behavior" during constant evaluation, even though it obviously is so at runtime. Of course, you can always issue a diagnostic and accept the program anyway.
Davis
Received on 2021-09-21 10:44:28