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

[Jim Thomas]

Here is a suggestion for changes to ISO/IEC TS 18661-4:2025 to address Issue #1014: Error handling in `<reduc.h>` and `<augarith.h>`:


In 6.1, before the paragraph beginning “For each of the following synopses, …”, and also in 7.1, before the paragraph beginning "For each of the following synopses, …”, add the paragraph:

For the terms “domain error” and “range error” used in the following subclauses, the specification in C23 7.12.2 pertains as though the functions were declared in <math.h>.

- Jim Thomas

> 
> 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/20250505/ad7ebbdc/attachment.htm>