Comment 6 for bug 2054101

Thank you both for the additional comments. I understand the distinction between normal and exceptional situations, and I have a solution to the problem that prompted me to file this (apparently buggy) bug report.

But for what it's worth, it still seems to me that the CL HyperSpec is violated in SBCL by the following variant of the example provided above, as I discuss below.

(defun f ()
  (declare (optimize (safety 3)))
  (null (* (eval 'most-positive-double-float)
           (eval 'most-positive-double-float))))

HyperSpec Section 12.1.4.3, "Rule of Float Underflow and Overflow", says that "An error of type floating-point-overflow or floating-point-underflow should be signaled if a floating-point computation causes exponent overflow or underflow, respectively." Section 1.4.2 says that when "An error should be signaled", then "Conforming code may rely on the fact that the error is signaled in safe code." I would expect the use of (safety 3) to make the above code safe. Yet (f) does not signal an error. Presumably that is because * is not called, but without an error being signaled by (f), I would expect Lisp call-by-value semantics to imply that actually, * should be called here. I suppose that must be where I'm mistaken, though I don't see why.