1. 28 Jun, 2017 3 commits
  2. 27 Jun, 2017 4 commits
    • Kris Katterjohn's avatar
      No longer allow PROGV to bind constants · 4e328370
      Kris Katterjohn authored
      PROGV was allowed to bind constants in the C-compiler and the bytecode
      compiler and interpreter, but the behavior would differ between them:
      
      > (defun foo ()
          (flet ((memq (item list) (member item list :test #'eq)))
            (progv (list :test) (list :test-not)
              (memq 'bar '(bar baz quux)))))
      FOO
      
      > (foo)
      (BAZ QUUX)
      
      > (compile 'foo)
      FOO
      
      > (foo)
      (BAR BAZ QUUX)
      
      CLHS says the behavior is undefined when attempting to bind or assign
      constant variables (CLHS 3.1.2.1.1.3 and the entry for defconstant).
      
      The C-compiler and bytecode compiler and interpreter give errors when
      attempting to bind or assign constant variables in lambda expressions,
      LET, SETQ and various other binding/assignment forms.  So the behavior
      above in PROGV is inconsistent.
      
      Now give an error when attempting to bind a constant variable in PROGV
      in the C-compiler and the bytecode compiler and interpreter.
      4e328370
    • Kris Katterjohn's avatar
      No longer allow M-V-B to bind constants in bytecode compiler/interpreter · c9e73262
      Kris Katterjohn authored
      M-V-B was allowed to lexically and dynamically bind constants in the
      bytecode compiler and interpreter:
      
      > (multiple-value-bind (pi rem) (truncate pi) pi)
      3
      
      CLHS says the behavior is undefined when attempting to bind or assign
      constant variables (CLHS 3.1.2.1.1.3 and the entry for defconstant).
      
      The C-compiler gives errors for these sorts of things, and the bytecode
      compiler and interpreter gives errors when attempting to bind or assign
      constant variables in lambda expressions, LET, SETQ and various other
      binding/assignment forms.  So the behavior above in M-V-B is
      inconsistent with the C-compiler and other parts of the bytecode
      compiler and interpreter.
      
      Now give an error when attempting to bind a constant variable in M-V-B
      in the bytecode compiler and interpreter.
      c9e73262
    • Kris Katterjohn's avatar
      No longer allow LET/LET* to bind constants in bytecode compiler/interpreter · 74568641
      Kris Katterjohn authored
      LET/LET* were allowed to lexically and dynamically bind constants in
      the bytecode compiler and interpreter:
      
      > (let ((pi 3)) pi)
      3
      
      > (progn (defconstant +c+ 'foo) (let ((+c+ 'bar)) +c+))
      BAR
      
      > (flet ((hello () (format t "hi")))
          (let ((t nil))
            (declare (special t))
            ; Oops, now this returns a string
            (hello)))
      "hi"
      
      Plus plenty of other ways to wreak havoc on unsuspecting code.
      
      CLHS says the behavior is undefined when attempting to bind or assign
      constant variables (CLHS 3.1.2.1.1.3 and the entry for defconstant).
      (Well, CLHS 3.4.1 explicitly says that constant variables cannot be
      used for variables in lambda lists.)
      
      The C-compiler gives errors for these sorts of things, and the bytecode
      compiler and interpreter gives errors when attempting to bind or assign
      constant variables in lambda expressions, SETQ and various other forms.
      So the behavior above in LET is inconsistent with both the C-compiler
      and other parts of the bytecode compiler and interpreter.
      
      Now give an error when attempting to bind a constant variable in
      LET/LET* in the bytecode compiler and interpreter.
      
      This also changes the behavior of PROG/PROG* and DESTRUCTURING-BIND so
      that they give errors when attempting to bind constants as well.
      74568641
    • Kris Katterjohn's avatar
      Check for a symbol before attempting to bind it in PROGV · 9ff1420c
      Kris Katterjohn authored
      PROGV was attempting to bind whatever was in its variable list
      without checking its type.  Using either the C-compiler or bytecode
      compiler/interpreter, the following example would lead to a segfault
      on my OpenBSD and Linux boxes:
      
      > (defun foo () (progv (list 3) (list 3)))
      FOO
      
      > (foo)
      Condition of type: SEGMENTATION-VIOLATION
      [...]
      
      Now give an error when attempting to bind something that is not a
      symbol in PROGV (in both the C-compiler and bytecode compiler and
      interpreter).
      9ff1420c
  3. 26 Jun, 2017 1 commit
  4. 23 Jun, 2017 4 commits
  5. 21 Jun, 2017 3 commits
  6. 13 Jun, 2017 2 commits
  7. 12 Jun, 2017 2 commits
  8. 06 Jun, 2017 1 commit
  9. 05 Jun, 2017 4 commits
  10. 03 Jun, 2017 5 commits
  11. 30 May, 2017 1 commit
  12. 26 May, 2017 1 commit
  13. 25 May, 2017 3 commits
  14. 22 May, 2017 1 commit
  15. 19 May, 2017 5 commits