I have a question. However, I spent longer writing this than I meant to, appending things as I figured them out, and haven't had the chance yet to test changes. I hope this will be helpful as-is.
> t-printf: format "%.100Lf" with LDBL_MAX unexpectly [sic] did not fail > FAIL: t-printf I see that this message comes from here: https://repo.or.cz/libgpg-error.mirror.git/blob/HEAD:/tests/t-printf.c#l477 It appears that it's trying to ensure that gpgrt_bsprintf("%.100Lf\n", (long double)LDBL_MAX) fails. We're expecting gpgrt_bsprintf() to fail, and calling it an error that it succeeds. I see at https://repo.or.cz/libgpg-error.mirror.git/blob/HEAD:/src/estream-printf.c#l1134 (inside a static helper function named 'pr_float()') there is mention of a static buffer sized just barely big enough so gpgrt_bsprintf("%.100f", DBL_MAX) will succeed. If this limit is pushed by trying to print a larger string, it is intended that an error should be returned to the caller. Perhaps the test is trying to see that this gets caught. With IBM "double-double" arithmetic, the number of bits for the exponent is still the same, and only the significand becomes effectively larger. So despite 'long double' being "bigger" than double (with HAVE_LONG_DOUBLE_WIDER defined correctly as per [1]), it needs no more decimal digits than double does to represent its LDBL_MAX. So it seems the error is the following assumption in the test: long double being "bigger" than double means printf("%Lf", LDBL_MAX) requires a bigger buffer than printf("%f", DBL_MAX) would (this is mistaken), and since the static buffer has been sized to be exactly right for the latter, it should be too small for the former. The test is surprised that printf("%Lf", LDBL_MAX) is able to make do with the small buffer, and so the test fails. With emphasis added by me, the autoconf manual says > If the C compiler supports a working long double type with more range **or** > precision than the double type, define HAVE_LONG_DOUBLE_WIDER. We have attained more precision, but not more range, but gpgrt assumes we have more range indeed. A condition would be sufficient for this to be, I think, is to see that LDBL_MAX_10_EXP is strictly greater than DBL_MAX_10_EXP (these constants being from float.h). [1] https://www.gnu.org/software/autoconf/manual/html_node/Particular-Types.html#index-AC_005fTYPE_005fLONG_005fDOUBLE_005fWIDER-1
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
