X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=2917c5c0de079278900137b8f69c0303b698b00b;hb=c43e3ee7e99bf8116402c2e6a90320b2e92b391b;hp=f7c265b8dde74bc930c2634b4ec36f2e6bd43714;hpb=b6fb1a4ad3fb9783148f1373e93edaf1f7e2d780;p=sbcl.git

diff --git a/BUGS b/BUGS
index f7c265b..2917c5c 100644
--- a/BUGS
+++ b/BUGS
@@ -883,11 +883,9 @@ WORKAROUND:
 283: Thread safety: libc functions
   There are places that we call unsafe-for-threading libc functions
   that we should find alternatives for, or put locks around.  Known or
-  strongly suspected problems, as of 0.8.3.10: please update this
+  strongly suspected problems, as of 1.0.3.13: please update this
   bug instead of creating new ones
 
-    gethostbyname, gethostbyaddr in sb-bsd-sockets
-
 284: Thread safety: special variables
   There are lots of special variables in SBCL, and I feel sure that at
   least some of them are indicative of potentially thread-unsafe 
@@ -1789,3 +1787,27 @@ WORKAROUND:
 	TYPE/= do, and writing an explanation which is so clear that one
 	can see immediately what it's supposed to mean in odd cases like
 	(TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet.
+
+409: MORE TYPE SYSTEM PROBLEMS
+  Found while investigating an optimization failure for extended
+  sequences. The extended sequence type implementation was altered to
+  work around the problem, but the fundamental problem remains, to wit:
+    (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio))
+                     (sb-kernel:specifier-type 'single-float))
+  returns NIL, NIL on sbcl-1.0.3.
+  (probably related to bug #408)
+
+410: read circularities and type declarations
+  Consider the definition
+    (defstruct foo (a 0 :type (not symbol)))
+  followed by
+    (setf *print-circle* t) ; just in case
+    (read-from-string "#1=#s(foo :a #1#)")
+  This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the
+  implementation of read circularity, using a symbol as a marker for
+  the previously-referenced object.
+
+411: NAN issues on x86-64
+  Test :NAN-COMPARISONS in float.pure.lisp fails on x86-64, and has been
+  disabled on those platforms. Since x86 does not exhibit any problems
+  the problem is probably with the new FP implementation.