Custom Query (1030 matches)

When a SIGFPE (or equivalent) is received, we need to try harder to determine the operation/operands to fully initialize the resulting ARITHMETIC-ERROR condition.

On x86, CCL::DECODE-ARITHMETIC-ERROR doesn't try very hard. On ARM, nothing tries at all (though we don't actually get a SIGFPE.)

The PPC ports disassembled the instruction that caused the exception; the other ports need to do the same thing.

The definition of TYPECASE, ETYPECASE and CTYPECASE in the standard (CLHS §5.3) allows that there be multiple clauses specifying a matching type. If a clause is completely shadowed by earlier clauses, the compiler may issue a warning. The type of the warning is explicitly mentioned to be STYLE-WARNING. The exact wording is as follows:

The compiler may choose to issue a warning of type style-warning if a clause will never be selected because it is completely shadowed by earlier clauses.

However, CCL issues a SIMPLE-WARNING in such situations, e. g.:

(block nil
  (handler-bind ((warning (lambda (w) (return (type-of w)))))
    (macroexpand '(typecase nr
                    (long-float #\L) 
                    (double-float #\D)
                    (short-float #\S)
                    (t #\E)))))
⇒ SIMPLE-WARNING

Which, I believe, contradicts the above disposition of the standard. One consequence is that, with ASDF, such a warning issued during the compilation of a file makes COMPILE-OP fail, signalling an error where, in fact, there should be none.

? (defclass test () ())
? (defmethod make-instance :around ((a standard-class) &rest args) (inspect (call-next-method)))
? (make-instance 'test)
Segfault