From: Douglas K. <do...@go...> - 2017-08-15 21:39:34
|
To your first question: yes, you asked for 0 safety, so memory fault is ok. Why shouldn't it allow you to pass wrong arguments in unsafe code? BAR is allowed to call FOO, and FOO is allowed to do anything stupid, such as crash. To your "also noted that": if FOO is declared to receive (INTEGER 9 100) and BAR declares X to conflict, then you'll get a compile-time warning because at runtime the types *will* be wrong. But NUMBER is not type disjoint from DOUBLE-FLOAT, so at runtime it only *might* be wrong. It could be right; so there's no warning. On Tue, Aug 15, 2017 at 5:10 PM, 73budden . <bud...@gm...> wrote: > Hi! The code is the following: > > (declaim (optimize (speed 3) (safety 0) (compilation-speed 0) (space > 0) (debug 0))) > > (declaim (ftype (function (double-float ) double-float) FOO )) > > (defun FOO (X) > (declare (type double-float X )) > (+ X 1.0d0) > ) > > (declaim (ftype (function (NUMBER ) NUMBER) BAR )) > > (defun BAR (X) > (declare (type NUMBER X)) > (FOO X) > ) > > (print (BAR 2)) > > Is that ok that I have "unhandled memory fault" instead of compilation > failure? With safety = 1 I get runtime check failure. Why SBCL allows > me to pass an argument to narrower number subtype? > > I also noted that I can pass (INTEGER 0 10) to a function that accepts > (INTEGER 9 100), but if I pass (INTEGER 0 5) then subtypes of integer > are disjoint and I get compilation failure. Is that ok? If so, is it > documented? > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |