0.7.6.19:
authorChristophe Rhodes <csr21@cam.ac.uk>
Tue, 13 Aug 2002 14:40:41 +0000 (14:40 +0000)
committerChristophe Rhodes <csr21@cam.ac.uk>
Tue, 13 Aug 2002 14:40:41 +0000 (14:40 +0000)
COMPILE-FILE-PATHNAME behaviour change (ANSI fix, probably)
... now with extra juicy MERGE-PATHNAMES logic
Fixes related to this change
... always absolutify pathnames in SBCL's build procedure
(with the TRUENAME-of-a-closed-file-stream trick)
... don't wander off into random memory if an arbitrary
stream is fed to a pathname function
NEWS update

NEWS
src/code/deftypes-for-target.lisp
src/code/target-pathname.lisp
src/cold/shared.lisp
src/compiler/main.lisp
tests/pathnames.impure.lisp
version.lisp-expr

diff --git a/NEWS b/NEWS
index b6464e0..29b3762 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1203,9 +1203,29 @@ changes in sbcl-0.7.7 relative to sbcl-0.7.6:
     or very deeply nested recursion) has changed.  Stack exhaustion
     detection is now done by write-protecting pages at the OS level
     and applies at all optimization settings; when found, a
-    SB-KERNEL:CONTROL-STACK_EXHAUSTED condition (subclass of
+    SB-KERNEL:CONTROL-STACK-EXHAUSTED condition (subclass of
     STORAGE-CONDITION) is signalled, so stack exhaustion can no longer
-    be caught using IGNORE-ERRORS
+    be caught using IGNORE-ERRORS.
+  * Bug 48a./b. fixed: SYMBOL-MACROLET now refuses to bind symbols
+    that are names of constants or global variables.
+  * Bug fix: DEFINE-ALIEN-ROUTINE now declaims the correct FTYPE for
+    alien routines with docstrings.
+  * Bug 184 fixed: Division of ratios by the integer 0 now signals an
+    error of type DIVISION-BY-ZERO. (thanks to Wolfhard Buss and
+    Raymond Toy)
+  * Bug fix: Errors in PARSE-INTEGER are now of type PARSE-ERROR.
+    (thanks to Eric Marsden)
+  * Bug fix: COERCE to (COMPLEX FLOAT) of rationals now returns an
+    object of type (COMPLEX FLOAT). (thanks to Wolfhard Buss)
+  * Bug fix: The SPARC backend can now compile functions involving
+    LOGAND and stack-allocated arguments. (thanks to Raymond Toy)
+  * Bug fix: We no longer segfault on passing a non-FILE-STREAM stream
+    to a functions expecting a PATHNAME-DESIGNATOR.
+  * Minor incompatible change: COMPILE-FILE-PATHNAME now merges its
+    OUTPUT-FILE argument with its INPUT-FILE argument, resulting in
+    behaviour analogous to RENAME-FILE.  This puts its behaviour more
+    in line with ANSI's wording on COMPILE-FILE-PATHNAME. (thanks to
+    Marco Antinotti)
 
 planned incompatible changes in 0.7.x:
 * When the profiling interface settles down, maybe in 0.7.x, maybe
index ff2401d..c153a2e 100644 (file)
 
 ;;; legal args to pathname functions
 (sb!xc:deftype pathname-designator ()
-  '(or string pathname stream))
+  '(or string pathname #+sb-xc-host stream #-sb-xc-host file-stream))
 (sb!xc:deftype logical-host-designator ()
   '(or host string))
 
index 5073954..9df17c6 100644 (file)
            (,pathname (etypecase ,pd0
                         (pathname ,pd0)
                         (string (parse-namestring ,pd0))
-                        (stream (file-name ,pd0)))))
+                        (file-stream (file-name ,pd0)))))
        ,@body)))
 
 ;;; Convert the var, a host or string name for a host, into a
index f17fedf..985a444 100644 (file)
     (when (probe-file obj)
       (delete-file obj))
 
-    ;; Work around a bug in CLISP 1999-01-08 #'COMPILE-FILE: CLISP
-    ;; mangles relative pathnames passed as :OUTPUT-FILE arguments,
-    ;; but works OK with absolute pathnames.
-    #+clisp
+    ;; Original comment:
+    ;;
+    ;;   Work around a bug in CLISP 1999-01-08 #'COMPILE-FILE: CLISP
+    ;;   mangles relative pathnames passed as :OUTPUT-FILE arguments,
+    ;;   but works OK with absolute pathnames.
+    ;;
+    ;; following discussion on cmucl-imp 2002-07
+    ;; "COMPILE-FILE-PATHNAME", it would seem safer to deal with
+    ;; absolute pathnames all the time; it is no longer clear that the
+    ;; original behaviour in CLISP was wrong or that the current
+    ;; behaviour is right; and in any case absolutifying the pathname
+    ;; insulates us against changes of behaviour. -- CSR, 2002-08-09
     (setf tmp-obj
          ;; (Note that this idiom is taken from the ANSI
          ;; documentation for TRUENAME.)
          (with-open-file (stream tmp-obj :direction :output)
            (close stream)
            (truename stream)))
+    ;; and some compilers (e.g. OpenMCL) will complain if they're
+    ;; asked to write over a file that exists already (and isn't
+    ;; recognizeably a fasl file), so
+    (when (probe-file tmp-obj)
+      (delete-file tmp-obj))
 
     ;; Try to use the compiler to generate a new temporary object file.
     (flet ((report-recompile-restart (stream)
index 88b0488..8834de1 100644 (file)
   #!+sb-doc
   "Return a pathname describing what file COMPILE-FILE would write to given
    these arguments."
-  (pathname output-file))
+  (merge-pathnames output-file (merge-pathnames input-file)))
 \f
 ;;;; MAKE-LOAD-FORM stuff
 
index 00da4c0..7898a29 100644 (file)
         (setf (logical-pathname-translations "")
               (list '("**;*.*.*" "/**/*.*")))))
 \f
+;;; Not strictly pathname logic testing, but until sbcl-0.7.6.19 we
+;;; had difficulty with non-FILE-STREAM stream arguments to pathname
+;;; functions (they would cause memory protection errors).  Make sure
+;;; that those errors are gone:
+(assert (raises-error? (pathname (make-string-input-stream "FOO"))
+                      type-error))
+(assert (raises-error? (merge-pathnames (make-string-output-stream))
+                      type-error))
+\f
 ;;;; success
 (quit :unix-status 104)
index f99bf07..1b37878 100644 (file)
@@ -18,4 +18,4 @@
 ;;; for internal versions, especially for internal versions off the
 ;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
 
-"0.7.6.18"
+"0.7.6.19"