On Sat, 23 Oct 2010, Landry Breuil wrote:
> i'm porting an app which uses:
> static gdouble line_speed = NAN;
> static gdouble line_course = NAN;
>
> which yields:
> gpspoint.c:84: error: initializer element is not constant
> gpspoint.c:85: error: initializer element is not constant
>
> Kirill Bychkov pointed out
> (http://marc.info/?l=openbsd-ports&m=128645629406557&w=2)
> to me that netbsd had the following related pr which affects us too:
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=40695
>
> Can we consider using the same libc fix ?
I'm with Mike in not seeing the benefit of the linker warning, especially
if the math.h change still uses __nan for the non-GCC case, or rather for
the not-gcc-3.3-or-newer case. The gcc2 platforms will obviously continue
to be non-compliant. ok guenther@ on the math.h bit.
> is the initialization using:
> static gdouble line_speed = __builtin_nanf("");
> static gdouble line_course = __builtin_nanf("");
>
> a valid temporary fix for the port ?
If gdouble is just double, then might as well use __builtin_nan("") to
avoid the float->double conversion. But I would think the first test
would be "does it compile, run, and work?"
Philip
