Division operator is optimized away if function is defined by macro, despite div-by-zero still being possible

Bug #2089599 reported by Patrick Poitras
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Invalid
Undecided
Unassigned

Bug Description

```
(defvar *zero* 0)
(defmacro bug-maker (name &body body)
  `(defun ,name () ,@body))
(bug-maker doesnt-error (/ 3 *zero*) nil)
(bug-maker errors (/ 3 *zero*))
(doesnt-error)
(errors)
```

Here, doesnt-error throws out the (/ 3 *zero*), likely because it's assuming that the result is pure and unused, therefore optimizes it away. This is despite division having a side-effect of throwing an error if division by zero occurs.

Bug reproduced on:

SBCL 2.3.3: 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
SBCL 2.4.10-1.1-suse: 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

*features*
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT
 :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
 :SB-THREAD :SB-UNICODE :SBCL :UNIX)

Revision history for this message
Stas Boukarev (stassats) wrote :

Have you ensured that this is in safe code?

Changed in sbcl:
status: New → Invalid
Revision history for this message
Patrick Poitras (pfpoitras) wrote :

This is in safe code, yes. If you mean like, there's no (safety 0) anywhere.

Revision history for this message
Stas Boukarev (stassats) wrote :
Revision history for this message
Patrick Poitras (pfpoitras) wrote :

Turns out the macro is irrelevant.

(defvar *zero* 0)
(defun blarg ()
  (/ 3 *zero*)
  nil)

Also removes it. I guess that makes it consistent, although unexpected.

Weirdly enough,
(defun blarg ()
  (/ 3 0) nil)

still throws an error, as does

(defun blarg ()
  (let ((zero 0))
     (/ 3 zero))
   nil)

I was expecting the default safety profile to maybe forego some type-checking, but not to alter runtime behavior to the extent that those two functions have different behavior than the first.

Is there more information somewhere about what the SBCL policy is on what the default safety mode is permitted to ignore, in terms of the side-effects of numerical functions or just any explanation, really?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.