Netbsd gets SIGFPE on alpha platform when calculating Inf

[Infinoid]

On alpha (for at least the netbsd OS), our PARROT_FLOATVAL_INF_POSITIVE macro results in SIGFPE, which causes some failing tests.

he++ submitted a patch with two related fixes. The first is to catch SIGFPE properly and ignore it. That's done with a signal() call at parrot init time, but there's a little confusion about the right place to put that. That part of the patch is a work in progress.

The second fix is to use math.h defines for Inf/-Inf/NaN on alpha, rather than trying to calculate the values directly.

[Infinoid]

Here's the current patch, contains some redundant code and could use some cleanup.

[heidnes]

Actually... The patch to src/main.c in the above can and should be deleted from the patchset, it was only present during initial testing, and I've also tested with it removed, and parrot still passes its test, since the platform misc.c / misc.h was added and does the same job.

I suspect also the patch to datatypes.h is no longer required now after we turned off SIGFPE, but it's an open question whether the NetBSD/alpha part of the patch should not be used universally, since the used constants are, as far as I know, standardized.

And ... This bug is not only related to handling of Inf, BTW, it's also the NaN handling which will in several cases land a SIGFPE, e.g. comparing a number with a NaN will by default trap.

[doughera]

Perl 5 uses fpsetmask(0) to avoid SIGFPE. That might be a good choice for parrot as well, though since parrot is also meant to be embedded, I have some hesitation setting such global policies.

In any case, avoiding things likely to generate SIGFPE is probably a good idea. Using the math.h #defines, when available, is almost certainly preferable to using the divide-by-zero trick. I'm sorry I wasn't paying enough attention when this came up earlier.

There are a number of ways to generate Inf and NaN, though different methods are likely needed on different platforms.

Using predefined constants from <math.h> (or similar) certainly is one, and seems to work on NetBSD (and probably other BSDs as well). It works on Linux, if the -std=c99 option is used, though that has other implications.

Using strtod("Infinity", (char **) NULL) or strtod("NaN", (char **)NULL) works on Solaris and Linux.

Using the current divide-by-zero trick seems to work on Linux, Mac, Solaris, and Windows. It's probably a good fallback.

That said, there are very few reasons to actually generate NaN or Inf anyway. I'm not sure why parrot does.

As for testing for NaN or Inf, the functions isnan() and isinf() are pretty widely available (and Parrot_signbit is already availble to test the sign).

In sum, I think this patch is a good step forward. After it is applied, it can probably even be generalized.

[Infinoid]

Thanks, committed as r38279. Some additional generalization sounds good.

[plobsing]

I have generalized this behaviour using a config probe to test for the system-provided macros in r49425.