Re: libgpg-error 1.61: t-printf failure on powerpc64-linux

--===============6420753802895988996==
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="=-YzT0ptY//1zEQ5NE1RY4"


--=-YzT0ptY//1zEQ5NE1RY4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have a question. However, I spent longer writing this than I meant to, ap=
pending things as I figured them out, and haven't had the chance yet to tes=
t 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.mi=
rror.git/blob/HEAD:/tests/t-printf.c#l477
It appears that it's trying to ensure that gpgrt_bsprintf("%.100Lf\n", (lon=
g double)LDBL_MAX) fails.

We're expecting gpgrt_bsprintf() to fail, and calling it an error that it s=
ucceeds. 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 tryin=
g 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 de=
spite '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 ass=
umption in the test: long double being "bigger" than double means printf("%=
Lf", LDBL_MAX) requires a bigger buffer than printf("%f", DBL_MAX) would (t=
his 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 su=
rprised that printf("%Lf", LDBL_MAX) is able to make do with the small buff=
er, 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 **o=
r** precision than the double type, define HAVE_LONG_DOUBLE_WIDER.
We have attained more precision, but not more range, but gpgrt assumes we h=
ave more range indeed.

A condition would be sufficient for this to be, I think, is to see that LDB=
L_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

--=-YzT0ptY//1zEQ5NE1RY4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iPsEABYKAKMWIQSiPzylvTnZ6xisfzWz9N0oYfTNugUCalfob3IYaHR0cHM6Ly9q
b2huc2NvdHQubWUvLndlbGwta25vd24vbmkvc2hhLTI1Ni9zWUF3OTN6QUVrRkIy
RDREM1hOemRSeHEyMFBjNnByZGdtbEVWeXo0QUZRP2N0PWFwcGxpY2F0aW9uJTJG
cGdwLWtleXMSHGpzY290dEBwb3N0ZW8ubmV0AAoJELP03Shh9M263msBAN8jpsD3
PQNCcn1UFhvNvwKSIhtb3kysq7Hgg5EdafE9AP47g48qx88sqdTWSuDuZui8Jrj1
b+rNDzqBKvRt4AE4BQ==
=vkOZ
-----END PGP SIGNATURE-----

--=-YzT0ptY//1zEQ5NE1RY4--


--===============6420753802895988996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users

--===============6420753802895988996==--