X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=ad30c7b996929c947c9d2499e7cb51ec7b791be7;hb=a18f0a95bc9a457e4d2d00c702b746f29c2662b1;hp=00f38e753c490b2f5e55cad5ca97d83807cbb30b;hpb=a8fa26a6e9804d3548f5bca9361a91345a689099;p=sbcl.git

diff --git a/BUGS b/BUGS
index 00f38e7..ad30c7b 100644
--- a/BUGS
+++ b/BUGS
@@ -225,10 +225,12 @@ WORKAROUND:
 
 26:
   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
-
-Also, there is another bug: `array-displacement' should return an array
-or nil as first value (as per ANSI CL), while CMUCL declares it as
-returning an array as first value always.
+    Also, there is another bug: `array-displacement' should return an
+    array or nil as first value (as per ANSI CL), while CMUCL declares
+    it as returning an array as first value always.
+  (Actually, I think the old CMU CL version in SBCL never returns NIL,
+  i.e. it's not just a declaration problem, but the definition doesn't
+  behave ANSIly.)
 
 27:
   Sometimes (SB-EXT:QUIT) fails with 
@@ -878,6 +880,28 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   multiple-VALUES types. (Some issues related to this were discussed
   on cmucl-imp at some length sometime in 2000.)
 
+95:
+  The facility for dumping a running Lisp image to disk gets confused
+  when run without the PURIFY option, and creates an unnecessarily large
+  core file (apparently representing memory usage up to the previous
+  high-water mark). Moreover, when the file is loaded, it confuses the
+  GC, so that thereafter memory usage can never be reduced below that
+  level.
+
+96:
+  The TRACE facility can't be used on some kinds of functions.
+  Basically, the breakpoint facility wasn incompletely implemented
+  in the X86 port of CMU CL, and we haven't fixed it in SBCL.
+
+97:
+  FRESH-LINE doesn't seem to work properly within pretty-printed
+  output. E.g. 
+    "~@<unhandled CONDITION (of type ~S): ~2I~_~A~:>~2%"
+  called on a CONDITION whose printer does
+    "~&~@<error in function ~S: ~3I~:_~?~:>"
+  gives two newlines between "unhandled CONDITION" and "error", when
+  (it at least seems as though) correct behavior would be to give one.
+
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER