Can Common Lisp type annotations result in unsound behavior? -
i know if safety setting low, common lisp can use type annotations optimization aids , not checked. example, program runs , prints both number , string without type errors. (i type error in sbcl, when safety >= 1)
(declaim (optimize (speed 3) (safety 0))) (defun f (x) (declare (type fixnum x)) x) (format t "1 ~a~%" (f 17)) (format t "2 ~a~%" (f "asd"))
i wonder if possible create program nasty things if safety set 0 , type annotations not respected. things casting 1 type (like c type casts) , other kinds of undefined behavior.
so far, haven't managed find out example that. tried variations of example uses typed arrays none of them resulted in typecasting behavior.
(declaim (optimize (speed 3) (safety 0) )) (defun f () (let ((arr (make-array '(5) :element-type 'fixnum :initial-contents (list 1 2 3 4 5)))) (declare (type (vector fixnum 5) arr)) (setf (aref arr 0) "hello") (aref arr 0))) (format t "a1 ~a~%" (f))
in clisp, program prints "hello", without doing typecast int , in sbcl program aborts simple-type-error error.
is there way create common lisp program results in demons coming out of nose if don't respect type declarations?
here couple of examples safety 0
in sbcl:
cl-user> (proclaim '(optimize (safety 0))) ; no value
out of bounds read
cl-user> (loop 0 20 (print (aref #(0) i))) 0 0 #(0) (i) nil (aref #(0) i) nil (print (aref #(0) i)) nil #<unknown immediate object, lowtag=#b1001, widetag=#x59 {d59}> #<sb-kernel:layout sb-kernel:lexenv {10005f3c33}> nil nil nil nil nil nil nil nil nil nil
undefined typecasting
cl-user> (defun f (x y) (declare (fixnum x y)) (+ x y)) f cl-user> (f t ()) 537919538
in sbcl if smell nasal demons can restart image , input (sb-ext:restrict-compiler-policy 'safety 3)
(and maybe again 'debug
, too) before loading problematic code. little luck nice condition instead of undefined behavior.
Comments
Post a Comment