[Cfp-interest 2597] Re: draft CFP response for NB comments and N3071

[Joseph Myers]

On Fri, 6 Jan 2023, Jim Thomas wrote:

> Here’s a draft for the CFP responses for NB comments on the C23 CD. The 
> responses are based on our review at the two CFP teleconferences this 
> week (January 4 and 5). Also, I have included a response with a proposal 
> for the issues raised in N3071.
> 
> Please review the paper and send any corrections or additions ASAP. Give 
> special attention to the section “About N3071”, much of which was 
> written after the CFP review meetings. I plan to update the draft, 
> incorporating your input, and submit it to WG14 on Monday, January 9.
> 
> https://wiki.edg.com/pub/CFP/WebHome/CFP_review_of_NB_comments-20230106.pdf

GB-164: I'll disagree with the disagreement here (I assume this will end 
up needing to be discussed in the WG14 meeting), since the semantic change 
in C2x (which I don't think was ever explicitly discussed as an intended 
semantic change in a paper) would make errno-setting implementations of 
various functions much more complicated and less efficient - detecting 
overflow after the fact (in a way that's valid for previous versions of C) 
by checking for an infinite results from finite arguments is very 
straightforward, determining based on the arguments whether pow, fdim, 
hypot or fma (for example) would overflow / whether a result of the 
largest finite value is an overflow is much more complicated and 
inefficient (and saving and restoring exceptions so as to test, for the 
purposes of errno setting, whether the overflow exception was raised, is 
also inefficient; such explicit manipulations of floating-point state are 
liable to empty the processor pipeline).  (This concern is specifically 
about errno setting rather than exceptions; ensuring the overflow 
exception is raised for overflow to a finite number isn't a problem in the 
same way.  So I'd be fine with applying the GB-164 change only for errno 
and not for exceptions.)

GB-279: The wording of some of the changes isn't quite right (constexpr 
isn't a storage *duration*, so wording shouldn't refer to it as such in 
F.8.4 or F.8.5).

N3071: "shall have the same type as the initializer" isn't quite right; 
the constexpr object is always (implicitly) const, but the initializer 
isn't because it's an rvalue, so it should rather be that the unqualified 
versions of the types are compatible (compatible is the usual notion, not 
same).  And I'd tend to expect a real sNaN to be suitable for initializing 
an object of the corresponding complex type (but not a different complex 
type), since no conversion is then applied to the real part - although I 
don't think any existing normative specification requires that to produce 
(sNaN, +0) as the result.

-- 
Joseph S. Myers
joseph at codesourcery.com