So, in conclusion, I think the way to proceed is to open a new ticket for the inconsistency between LWG issue 231 and punct.cpp and treat it separately from STDCXX-2. FWIW, I was about to add it but Jira appears to be down at the moment...
Martin Farid Zaripov wrote:
The 22.locale.num.put.stdcxx-2 regression test fails on gcc/Linux (and I suppose that fails on every compiler on non-Windows platform). The fail is caused when precision is 0, and in this case the precision is not used in sprintf() format string generated by __rw_get_stdio_fmat(). As a result the default precision equal to 6 is used. As I understand the lwg issue 231 resolution, the precision should be used always for conversions from a floating-point type: 22.2.2.2.2 p5 "For conversion from a floating-point type, str .precision() is specified in the conversion specification." The proposed patch below: Index: src/punct.cpp =================================================================== --- src/punct.cpp (revision 631177) +++ src/punct.cpp (working copy) @@ -619,9 +619,7 @@ const int fltfld = fmtflags & _RWSTD_IOS_FLOATFIELD;// follows resolution of lwg issue 231- if ( ( _RWSTD_IOS_FIXED == fltfld - || _RWSTD_IOS_SCIENTIFIC == fltfld) - && prec >= 0 || prec > 0) { + if (0 <= prec) {// 7.19.6.1, p5 of C99 specifies that, when given using the// asterisk, negative precision is treated the same as if Farid.
