made debugger handle errors in printing *DEBUG-CONDITION*

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index fbfc496..71f2d77 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -5,8 +5,8 @@ Bugs can be reported on the help mailing list
 or on the development mailing list
   sbcl-devel@lists.sourceforge.net
 
 or on the development mailing list
   sbcl-devel@lists.sourceforge.net
 

-Please please please include enough information in a bug report
-that someone reading it can reproduce the problem, i.e. don't write
+Please include enough information in a bug report that someone reading
+it can reproduce the problem, i.e. don't write

      Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
      PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
 but instead
      Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
      PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
 but instead

@@ -22,12 +22,6 @@ but instead
      the program loops endlessly instead of printing the object.
 
 
      the program loops endlessly instead of printing the object.
 
 

-KNOWN PORT-SPECIFIC BUGS
-
-OpenBSD-1:
-  The breakpoint-based TRACE facility doesn't work properly
-  in the OpenBSD port of sbcl-0.6.7.
-

 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 At some point, the pure interpreter (aka the "IR1 interpreter") will
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 At some point, the pure interpreter (aka the "IR1 interpreter") will

@@ -49,6 +43,7 @@ IR1-2:
        * (COMPILED-FUNCTION-P #'FOO)
        T
 
        * (COMPILED-FUNCTION-P #'FOO)
        T
 

+

 OTHER KNOWN BUGS:
 
 (There is also some information on bugs in the manual page and in the
 OTHER KNOWN BUGS:
 
 (There is also some information on bugs in the manual page and in the

@@ -75,7 +70,7 @@ TODO file. Eventually more such information may move here.)
   specifically required by the ANSI spec.)
 
 4:
   specifically required by the ANSI spec.)
 
 4:

-  It should cause a STYLE-WARNING, not a WARNING, when the system ignores
+  It should cause a note, not a WARNING, when the system ignores

   an FTYPE proclamation for a slot accessor.
 
 5:
   an FTYPE proclamation for a slot accessor.
 
 5:

@@ -712,9 +707,6 @@ SBCL: (("blah") ("blah2"))
        b: READ should probably return READER-ERROR, not the bare 
           arithmetic error, when input a la "1/0" or "1e1000" causes
           an arithmetic error.
        b: READ should probably return READER-ERROR, not the bare 
           arithmetic error, when input a la "1/0" or "1e1000" causes
           an arithmetic error.

-       c: (BUTLAST NIL) should return NIL. (This appears to be a compiler
-          bug, since the definition of BUTLAST, when interpreted, does
-          give (BUTLAST NIL)=>NIL.)

 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 
 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 

@@ -746,18 +738,16 @@ SBCL: (("blah") ("blah2"))
 Error in function C::GET-LAMBDA-TO-COMPILE:
    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
 
 Error in function C::GET-LAMBDA-TO-COMPILE:
    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
 

-57:
-  In sbcl-0.6.7, the compiler accepted a bogus declaration
-  (TYPE INDEX LENGTH) in the definition of BUTLAST, and then died
-  with infinite regress of errors when the BUTLAST function was
-  executed with a LIST=NIL which would cause LENGTH to be -1.
-  I fixed the bogus declaration, but I should come back and see
-  whether the system's inability to recover from the bogus declaration
-  (by signalling a TYPE-ERROR and dropping into the debugger) was 
-  a compiler problem which remains to be fixed, or one of the 
-  unrelated infinite-regress-errors problems, many related to 
-  revised signal handling, which were fixed around the same time.
-

 58:
   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
   => NIL, NIL
 58:
   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
   => NIL, NIL

+
+59:
+  CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
+  current working directory). And there's no supported way to update
+  or query the current working directory (a la Unix "chdir" and "pwd"),
+  which is functionality that ILISP needs (and currently gets with low-level
+  hacks).
+
+60:
+  The debugger LIST-LOCATIONS command doesn't work properly.