Re: strtod.c compilation failure on i386/Solaris 10

[Jim Meyering]

Eric Blake <address@hidden> wrote:

> According to Jim Meyering on 4/12/2008 1:46 AM:
> | In wading through coreutils build reports for 60+ systems, I see a new
> failure:
> |
> |   strtod.c: In function `rpl_strtod':
> |   strtod.c:155: error: incompatible types in assignment
> |   strtod.c:170: error: incompatible types in assignment
> |   strtod.c:257: error: wrong type argument to unary minus
> |   make[3]: *** [strtod.o] Error 1
>
> You're not the first to report it:
> http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00034.html
>
> |
> | Here are the lines in question, each followed by cpp-translated code:
> |
> |               num = HUGE_VAL;
> |           num = __builtin_huge_val;
> |
> |               num = NAN;
> |           num = __builtin_nan;
>
> However, you were the first to provide the information I asked for when
> the problem was first mentioned.  So, what types exactly are __builtin_nan
> and __builtin_huge_val on Solaris 10 (NAN is supposed to be float, and
> while HUGE_VAL is supposed to be double, I suspect __builtin_huge_val
> might be float to feed all four of HUGE_VAL, HUGE_VALF, HUGE_VALL, and
> INFINITY)?  Does adding an explicit cast work around the compiler bug of
> warning about what is supposed to be a safe implicit cast?

Thanks for the quick reply (yes, I owe you at least one ;-).

These are from gcc, so I looked in gcc's own extend.texi
and saw that they are functions.  Here are examples that compile:

  double d = __builtin_huge_val();
  double e = __builtin_nan("0x0");