In article <1hw1cj7.s1lal11ygc4jrM%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
>Thor Lancelot Simon <tls@rek.tjls.com> wrote:
>
>> > What do you mean? The case where the object is not a float? I'm in case
>> > CT_FLOAT, so this should be adressed...
>> 
>> No.  Not all floating-point formats have "not a number" or IEEE-style
>> infinities, and we run on at least two machines where there is no
>> floating point format that does, plus at least one where one of the
>> available floating points doesn't (though we don't support it).
>
>Please give more details, I'm really clueless on this topic.
>
>I try to fix that bug:
>
>#include <stdio.h>
>#include <math.h>
>
>int
>main(void)
>{
>        float f,g;
>        int hit;
>        char s[512];
>
>        f = sqrt(-1);
>
>        printf("f = %f\n", f);
>        snprintf(s, sizeof(s), "%f", f);
>        printf("s = \"%s\"\n", s);
>        hit = sscanf(s, "%f", &g);
>        printf("hit = %d\n", hit);
>        printf("g = %f\n\n", g);
>
>        return 0;
>}
>
>On -current, this produces:
>f = nan
>s = "nan"
>hit = 0
>g = 0.000000
>
>With my patch:
>f = nan
>s = "nan"
>hit = 1
>g = nan
>
>Can you give me an example where the patch would not be appropriate?

There are machines that don't have NaN or Inf like the vax. In that
case the input would be "inf" or "nan" and g would print a real number.
The patch is fine for machines with "inf" and "nan". I am not sure
what the best way is to approach this for machines that don't have
"inf" or "nan". Perhaps the code should just not match "inf" and "nan"
for machines that don't have them and behave like it does now.

christos