[PATCH] Fix hpux10 string to real conversion defficiences

[FX Coudert]

>> The change could be improved if a check were added to configure to
>> test the capability of strtod and friends to handle nan, inf and
>> infinity.  However, it's not clear to me how to do this except by
>> hard coding the result.
> It think one can test it in configure along these lines
>  a = strtod ("nan", NULL); if(a == a) abort();
>  a = strtod("+inf", NULL); if(a != a || a != a + 1.0 || a < 0.0)  
> abort();
>  a = strtod("-inf", NULL); if(a != a || a != a - 1.0 || a > 0.0)  
> abort();

I also am in favour of a configure test. You can look into  
libgfortran/acinclude.m4 to see how LIBGFOR_CHECK_FOR_BROKEN_ISNAN  
works, for example.

> (The disadvantage of a run test is of cause that it does not work  
> if you build for a target which is different from your system used  
> for building gcc.)

But... you can give target-specific sensible defaults for cross- 
compilers. In LIBGFOR_CHECK_FOR_BROKEN_ISNAN, for example, the  
default is:

> case "${target}" in
>   hppa*-*-hpux*) have_broken_isnan=yes ;;
>   *) have_broken_isnan=no ;;
> esac


In LIBGFOR_CHECK_CRLF, we have:

> case "${target}" in
>   *mingw*) have_crlf=yes ;;
>   *) have_crlf=no;;
> esac


It is painful to maintain for cases where there are many targets  
passing the test and many targets failing, but when you have one  
result expected and only a few targets failing, it's quite acceptable.

> Besides, I somehow fear that your current version is rather slow  
> for big ascii files. (It is not uncommon to read relatively large  
> ascii files with data in numerics.)

I also agree. Moreover, systems having poor libc (and thus poor  
strtod) might not have strcasecmp, so I favour a character comparison  
approach.

FX

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/