Error is not signalled in tagbody
Bug #1910098 reported by
il71
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
sbcl 2.1.0
This loops forever:
(let ((x 0) (y 0))
(tagbody
a
(setf x 5)
(setf y 0)
(if (zerop (mod x y)) (go a))))
or with dummy tagbody:
(let ((x 0) (y 0))
(tagbody
(setf x 5)
(setf y 0)
(mod x y)))
=> NIL
Changed in sbcl: | |
status: | New → Fix Committed |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Starting with the second example first, it can be explained in one of two ways. In safety less than 3, you're not supposed to call a function purposely wrongly "just" to signal an error because calling it wrongly is not defined behavior. So the compiler is free to assume that you're not doing that. Hence because the result is unused, the compiler may return NIL from the tagbody because MOD is not being used for its value. But regardless of safety, I believe it's always permissible because MOD is defined in terms of FLOOR which is defined in terms of / which says "Might signal type-error ... Might signal division-by-zero if division by zero is attempted. Might signal arithmetic-error" and "might" is defined such that _if_ an error is signaled, it is of the specified type. Though in safety 3 it would be better to signal the error than silently ignore.
The first example is a little funny because MOD is clearly used for its value, so it looks arbitrary that the compiler decided that the result of ZEROP is true.