Hi,
Seeking some guidance on what action I should take to get this bug fixed.
Here's the demo:
/* filename is bug.c */
/*
built with:
gcc -o bug bug.c -lquadmath
assumes 80-bit extended precision long double
*/
/* for Windows ... should not interfere with *nix */
#ifndef __USE_MINGW_ANSI_STDIO
#define __USE_MINGW_ANSI_STDIO 1
#endif
#include <stdio.h>
#include <quadmath.h>
#include <stdlib.h>
#include <float.h>
int main(void) {
__float128 f128;
long double ld;
char buf1[8];
int i;
void *pld = &ld, *pf128 = &f128;
ld = strtold("inf", NULL);
printf("ld is: ");
for (i = 9; i >= 0; i--)
printf("%02x", ((unsigned char*)pld)[i]);
printf("\n");
printf("%Le\n",ld);
if(ld != ld) printf("ld behaves like a NaN\n");
else printf("ld does NOT behave as a NaN\n");
f128 = (__float128)ld;
printf("f128 is: ");
for (i = 15; i >= 0; i--)
printf("%02x", ((unsigned char*)pf128)[i]);
printf("\n");
if(f128 != f128) printf("Looks like we have a NaN instead of Inf\n");
quadmath_snprintf(buf1, 6, "%Qe", f128);
printf("%s\n", buf1);
return 0;
}
For me, on Windows (gcc versions 4.9.2 & 5.3.0, mingw runtime versions 3.x
and 4.x), this outputs:
###################################
ld is: 7fff8000000000000000
inf
ld does NOT behave as a NaN
f128 is: 7fff8000000000000000000000000000
Looks like we have a NaN instead of Inf
nan
###################################
I believe it will also produce the same output with Debian ports of 4.9.3,
5.4.0, and 6.1.1 - libc6 version 2.22-11.
The value returned by strtold("inf",NULL) appears to me to have the
structure of a NaN - yet behaves as an Inf.
It's only when this long double value is cast to __float128 that it behaves
as a NaN.
Where to from here ?
Cheers,
Rob
