Hello,
t-printf fails on armhf with:
t-printf: format "%.100Lf" with LDBL_MAX unexpectly did not fail
FAIL: t-printf
Git bisect pointed to f7ded3ce666ca8e27226dfa05b1e6b8636728441 as offending commit.
Description
Description
Details
Details
- Version
- 1.61
Revisions and Commits
Revisions and Commits
Related Objects
Related Objects
Event Timeline
Comment Actions
In https://en.cppreference.com/c/language/arithmetic_types#Real_floating_types , it says
long double — extended precision floating-point type. Matches IEEE-754 binary128 format if supported, otherwise matches IEEE-754 binary64-extended format if supported, otherwise matches some non-IEEE-754 extended floating-point format as long as its precision is better than binary64 and range is at least as good as binary64, otherwise matches IEEE-754 binary64 format. * binary128 format is used by some HP-UX, SPARC, MIPS, ARM64, and z/OS implementations. * The most well known IEEE-754 binary64-extended format is 80-bit x87 extended precision format. It is used by many x86 and x86-64 implementations (a notable exception is MSVC, which implements long double in the same format as double, i.e. binary64).
So, it (long double type, and the value LDBL_MAX) can be IEEE-754 binary64 (the same format as double), with the value of 1.7976931348623157e+308.
This value can be represented with the internal buffer size of libgpg-error implementation.
I don't know about exact limit of armhf, but for the portability, the test need to be fixed.
Comment Actions
Here is the fix:
diff --git a/configure.ac b/configure.ac index e9abe0d..7871769 100644 --- a/configure.ac +++ b/configure.ac @@ -276,6 +276,7 @@ AC_C_CONST AC_CHECK_SIZEOF(int) AC_CHECK_SIZEOF(long) AC_CHECK_SIZEOF(long long) +AC_TYPE_LONG_DOUBLE_WIDER GNUPG_FUNC_MKDIR_TAKES_ONE_ARG diff --git a/tests/t-printf.c b/tests/t-printf.c index 6cbd03f..b0a3f3f 100644 --- a/tests/t-printf.c +++ b/tests/t-printf.c @@ -449,7 +449,7 @@ check_large_float (void) errno, strerror (errno)); } else if (verbose) - show ("format \"%%.100f\" with DBL_MAX: ->%s<-\n", buf2); + show ("format \"%%.101f\" with DBL_MAX: ->%s<-\n", buf2); if (strcmp (buf, buf2)) fail ("format \"%%.100f\" does not match \"%%.101f\"\n" ); @@ -469,6 +469,7 @@ check_large_float (void) show ("format \"%%.100Lf\" with DBL_MAX: ->%s<-\n", buf); gpgrt_free (buf); +# ifdef HAVE_LONG_DOUBLE_WIDER ld = LDBL_MAX; buf = gpgrt_bsprintf ("%.100Lf\n", ld); if (buf) @@ -478,6 +479,10 @@ check_large_float (void) else if (verbose) show ("format \"%%.100Lf\" with LDBL_MAX failed as expected\n"); gpgrt_free (buf); +# else + if (verbose) + show ("LDBL_MAX == DBL_MAX - skipping LDBL_MAX test\n"); +# endif #endif /*HAVE_LONG_DOUBLE*/ }
I haven't tested on the particular architecture yet. Only tested on machines with HAVE_LONG_DOUBLE_WIDER.
Comment Actions
I found the AC_TYPE_LONG_DOUBLE_WIDER check in rsync.
I confirmed this build on armhf: https://buildd.debian.org/status/fetch.php?pkg=rsync&arch=armhf&ver=3.4.4%2Bds1-1&stamp=1780897385&raw=0
checking for long double with more range or precision than double... no
So, I'm going to commit the change above.