[cfp-interest 3424] Fwd: [SC22WG14.30159] New issue #1014: Error handling in `<reduc.h>` and `<augarith.h>`

[Jim Thomas]

Here’s a suggestion for changes to TS 18661-4:2025 to address issue #1014. In 6.1, before the paragraph beginning "Whether and how rounding direction modes affect functions …”, and in 7.1, before the paragraph beginning "The functions in this clause round to nearest …”, add the paragraph:

For the terms “domain error” and “range error” used in this subclause, the specification in C23 7.12.2 pertains.

A preliminary question is how issues against TSes are to be dealt with (revision, errata, or other).

- Jim Thomas


> Begin forwarded message:
> 
> From: Joseph Myers <josmyers at redhat.com>
> Subject: [SC22WG14.30159] New issue #1014: Error handling in `<reduc.h>` and `<augarith.h>`
> Date: March 27, 2025 at 3:20:52 PM PDT
> To: sc22wg14 at open-std.org
> 
> The following new C standard issue has been submitted.
> 
> https://www.open-std.org/jtc1/sc22/wg14/issues/cfp-c23/issue1014.html
> 
> ## Issue 1014: Error handling in `<reduc.h>` and `<augarith.h>`
> 
> Authors: Joseph Myers  
> Date: 2025-03-27  
> Submitted against: Floating-point TS 18661 (C23 version, 2025)  
> Status: Open
> 
> TS 18661-4:2025 talks about domain errors and range errors for
> functions in `<reduc.h>` and `<augarith.h>`.
> 
> In the first (2015) edition of TS 18661-4, the functions were
> described as being added to `<math.h>` so it was clear that the error
> handling semantics for `<math.h>` described in the C standard applied.
> With the functions now being in new headers, it is no longer clear
> whether those semantics (C23 7.12.2 (Treatment of error conditions))
> apply to these functions, or whether different semantics might apply
> (such as the `<complex.h>` semantics where setting `errno` is optional
> even when the value of `math_errhandling` means it must be set by
> `<math.h>` functions).
> 
> An explicit statement should be added, either applying the rules from
> `<math.h>` to error handling for functions in the new headers, or
> stating how error handling requirements differ from those in
> `<math.h>`.  (No specific wording is proposed here.)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20250407/89139885/attachment.htm>