It might be easier to follow if related topics were grouped together in the same section. For example, it could be clearer to place items such as - `from_chars` and `to_chars` (<charconv> support)
- `strtod` family (<stdlib> support)
under a common section like "IO and String Conversions".
Based off of the comments there will be another round of re-organization. I thought that having every function under it's analogous STL header, but that has clearly been shown to not be the case.
Here are a few comments on the two design choices noted above:
* CR on mandatory operations - It would help to document the downsides of not providing CR: * Even when using reproducible operations (see e.g. IEEE 754 Clause 11), results may diverge from CR libraries (e.g. Intel's decimal library). If a compiler's decimal FP backend uses such a CR library, results may also diverge from the C23 standard library.
The Intel Library's README is not correctly rounded for all operations either, and states as much (which I quote in the docs). I can add in a line that says results will differ in the last few ULPs. You will find that even between standard library implementations for binary-floating point math results will vary outside of 0.5 ULPs.
<Conclusion>
I recommend Conditional Accept, on the condition that a setup is provided to run decTest regularly (e.g. as part of CI).
Can you share the test harness that you've already built? I never put effort into them because the copyright All Rights Reserved IBM precludes them from being checked into the repo or modified like your previous comments call out. I don't really want to spam downloading from Mike's website, but he at least has the disclaimer of reproduced with permission from IBM. Thank you for your review and working with us on bug reports in the weeks leading up to the review! Matt