When making foreign function calls (with sb-alien or a wrapper such as cffi), sbcl will trap floating point errors that happen in the C code, and by default sbcl traps on errors that aren't typically on in c code (the default mode in C99 is to be in nonstop mode, ie no fp exceptions trigger a SIGFPE)
So, the C compiler compiled erroneous C code, which when executed (the C program) runs fine, whereas SBCL is signalling something is wrong with it? Hence the need to do:
(sb-int:with-float-traps-masked
(:divide-by-zero :invalid)
(some-function-or-whatever))
Am I understanding that right?
More like, that program has a bug or isn’t being invoked correctly and the side-effect is it’s triggering an fpe.
It’s possible there’s actually some error handling logic later on in the code that would either correct the error, explain what’s wrong, or at return an actually useful error code.
But because SBCL turns on float traps the C code never gets passed the fpe.
Once it hits the fpe SBCL’s debugger takes over.
It’s not that the compiler emitted bad code, it’s that most C programs expect to get NaNs back when they screw up float computations instead of signals getting sent to their process.
Any C code that actually relies on getting NaNs to detect errors doesn’t work correctly when called by SBCL.