Skip to content
This repository
tag: sbcl.0.8.13
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 1572 lines (1375 sloc) 64.998 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571
REPORTING BUGS

Bugs can be reported on the help mailing list
  sbcl-help@lists.sourceforge.net
or on the development mailing list
  sbcl-devel@lists.sourceforge.net

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*?)
     In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
     I compile and load the file
       (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
(LET ((*PRINT-LENGTH* 4))
(PRINT X Y)))))
X Y)
     then at the command line type
       (MAKE-FOO)
     the program loops endlessly instead of printing the object.


NOTES:

There is also some information on bugs in the manual page and
in the TODO file. Eventually more such information may move here.

The gaps in the number sequence belong to old bug descriptions which
have gone away (typically because they were fixed, but sometimes for
other reasons, e.g. because they were moved elsewhere).


2:
  DEFSTRUCT almost certainly should overwrite the old LAYOUT information
  instead of just punting when a contradictory structure definition
  is loaded. As it is, if you redefine DEFSTRUCTs in a way which
  changes their layout, you probably have to rebuild your entire
  program, even if you know or guess enough about the internals of
  SBCL to wager that this (undefined in ANSI) operation would be safe.

3: "type checking of structure slots"
  a:
  ANSI specifies that a type mismatch in a structure slot
  initialization value should not cause a warning.
WORKAROUND:
  This one might not be fixed for a while because while we're big
  believers in ANSI compatibility and all, (1) there's no obvious
  simple way to do it (short of disabling all warnings for type
  mismatches everywhere), and (2) there's a good portable
  workaround, and (3) by their own reasoning, it looks as though
  ANSI may have gotten it wrong. ANSI justifies this specification
  by saying
    The restriction against issuing a warning for type mismatches
    between a slot-initform and the corresponding slot's :TYPE
    option is necessary because a slot-initform must be specified
    in order to specify slot options; in some cases, no suitable
    default may exist.
  However, in SBCL (as in CMU CL or, for that matter, any compiler
  which really understands Common Lisp types) a suitable default
  does exist, in all cases, because the compiler understands the
  concept of functions which never return (i.e. has return type NIL).
  Thus, as a portable workaround, you can use a call to some
  known-never-to-return function as the default. E.g.
    (DEFSTRUCT FOO
      (BAR (ERROR "missing :BAR argument")
           :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
  or
    (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
    (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
      (ERROR "missing required argument"))
    (DEFSTRUCT FOO
      (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
      (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
      (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
  Such code should compile without complaint and work correctly either
  on SBCL or on any other completely compliant Common Lisp system.

  b: &AUX argument in a boa-constructor without a default value means
     "do not initilize this slot" and does not cause type error. But
     an error may be signalled at read time and it would be good if
     SBCL did it.

  d: (fixed in 0.8.1.5)

7:
  The "compiling top-level form:" output ought to be condensed.
  Perhaps any number of such consecutive lines ought to turn into a
  single "compiling top-level forms:" line.

19:
  (I *think* this is a bug. It certainly seems like strange behavior. But
  the ANSI spec is scary, dark, and deep.. -- WHN)
    (FORMAT NIL "~,1G" 1.4) => "1. "
    (FORMAT NIL "~3,1G" 1.4) => "1. "

27:
  Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
Process inferior-lisp exited abnormally with code 1
  I haven't noticed a repeatable case of this yet.

32:
  The printer doesn't report closures very well. This is true in
  CMU CL 18b as well:
    (PRINT #'CLASS-NAME)
  gives
    #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
  It would be nice to make closures have a settable name slot,
  and make things like DEFSTRUCT and FLET, which create closures,
  set helpful values into this slot.

33:
  And as long as we're wishing, it would be awfully nice if INSPECT could
  also report on closures, telling about the values of the bound variables.

35:
  The compiler assumes that any time a function of declared FTYPE
  doesn't signal an error, its arguments were of the declared type.
  E.g. compiling and loading
    (DECLAIM (OPTIMIZE (SAFETY 3)))
    (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
    (DEFUN GAMMA (X) X)
    (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
    (DEFUN FOO (X)
      (COND ((> (FACTORIAL X) 1.0E6)
             (FORMAT T "too big~%"))
            ((INTEGERP X)
             (FORMAT T "exactly ~S~%" (FACTORIAL X)))
            (T
             (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
  then executing
    (FOO 1.5)
  will cause the INTEGERP case to be selected, giving bogus output a la
    exactly 2.5
  This violates the "declarations are assertions" principle.
  According to the ANSI spec, in the section "System Class FUNCTION",
  this is a case of "lying to the compiler", but the lying is done
  by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
  not by the unexpectedly general definition of FACTORIAL. In any case,
  "declarations are assertions" means that lying to the compiler should
  cause an error to be signalled, and should not cause a bogus
  result to be returned. Thus, the compiler should not assume
  that arbitrary functions check their argument types. (It might
  make sense to add another flag (CHECKED?) to DEFKNOWN to
  identify functions which *do* check their argument types.)
  (Also, verify that the compiler handles declared function
  return types as assertions.)

42:
  The definitions of SIGCONTEXT-FLOAT-REGISTER and
  %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
  supported on FreeBSD because the floating point state is not saved,
  but at least as of FreeBSD 4.0, the floating point state *is* saved,
  so they could be supported after all. Very likely
  SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.

60:
  The debugger LIST-LOCATIONS command doesn't work properly.
  (How should it work properly?)

61:
  Compiling and loading
    (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
    (FAIL 12)
  then requesting a BACKTRACE at the debugger prompt gives no information
  about where in the user program the problem occurred.

64:
  Using the pretty-printer from the command prompt gives funny
  results, apparently because the pretty-printer doesn't know
  about user's command input, including the user's carriage return
  that the user, and therefore the pretty-printer thinks that
  the new output block should start indented 2 or more characters
  rightward of the correct location.

67:
  As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
  and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
  crashes SBCL. In general tracing anything which is used in the
  implementation of TRACE is likely to have the same problem.

78:
  ANSI says in one place that type declarations can be abbreviated even
  when the type name is not a symbol, e.g.
    (DECLAIM ((VECTOR T) *FOOVECTOR*))
  SBCL doesn't support this. But ANSI says in another place that this
  isn't allowed. So it's not clear this is a bug after all. (See the
  e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
  and Pierre Mai.)

83:
  RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
  RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
  the mean of the distribution can be systematically O(0.1%) wrong.
  Just increasing R-I-E-B is probably not a good solution, since
  it would decrease efficiency more than is probably necessary. Perhaps
  using some sort of accept/reject method would be better.

85:
  Internally the compiler sometimes evaluates
    (sb-kernel:type/= (specifier-type '*) (specifier-type t))
  (I stumbled across this when I added an
    (assert (not (eq type1 *wild-type*)))
  in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
  in a type context should probably be translated to T, and so it's
  probably wrong to ask whether it's equal to the T type and then (using
  the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
  (I haven't tried to investigate this bug enough to guess whether
  there might be any user-level symptoms.)

  In fact, the type system is likely to depend on this inequality not
  holding... * is not equivalent to T in many cases, such as
    (VECTOR *) /= (VECTOR T).

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.

  (As of 0.8.7.3 it's likely that the latter half of this bug is fixed.
  The interaction between gencgc and the variables used by
  save-lisp-and-die is still nonoptimal, though, so no respite from
  big core files yet)

98:
  In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
  CL), out-of-line structure slot setters are horribly inefficient
  whenever the type of the slot is declared, because out-of-line
  structure slot setters are implemented as closures to save space,
  so the compiler doesn't compile the type test into code, but
  instead just saves the type in a lexical closure and interprets it
  at runtime.
    To exercise the problem, compile and load
      (cl:in-package :cl-user)
      (defstruct foo
        (bar (error "missing") :type bar))
      (defvar *foo*)
      (defun wastrel1 (x)
        (loop (setf (foo-bar *foo*) x)))
      (defstruct bar)
      (defvar *bar* (make-bar))
      (defvar *foo* (make-foo :bar *bar*))
      (defvar *setf-foo-bar* #'(setf foo-bar))
      (defun wastrel2 (x)
        (loop (funcall *setf-foo-bar* x *foo*)))
  then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
  use BACKTRACE, to see it's spending all essentially all its time
  in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
    One possible solution would be simply to give up on
  representing structure slot accessors as functions, and represent
  them as macroexpansions instead. This can be inconvenient for users,
  but it's not clear that it's worse than trying to help by expanding
  into a horribly inefficient implementation.
    As a workaround for the problem, #'(SETF FOO) expressions
  can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
(defmacro efficient-setf-function (place-function-name)
  (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
;; a workaround for the problem, encouraging the
;; inline expansion of the structure accessor, so
;; that the compiler can optimize its type test
(let ((new-value (gensym "NEW-VALUE-"))
                        (structure-value (gensym "STRUCTURE-VALUE-")))
`(lambda (,new-value ,structure-value)
(setf (,place-function-name ,structure-value)
,new-value))))
      ;; no problem, can just use the ordinary expansion
      `(function (setf ,place-function-name))))

100:
  There's apparently a bug in CEILING optimization which caused
  Douglas Crosher to patch the CMU CL version. Martin Atzmueller
  applied the patches to SBCL and they didn't seem to cause problems
  (as reported sbcl-devel 2001-05-04). However, since the patches
  modify nontrivial code which was apparently written incorrectly
  the first time around, until regression tests are written I'm not
  comfortable merging the patches in the CVS version of SBCL.

108:
  (TIME (ROOM T)) reports more than 200 Mbytes consed even for
  a clean, just-started SBCL system. And it seems to be right:
  (ROOM T) can bring a small computer to its knees for a *long*
  time trying to GC afterwards. Surely there's some more economical
  way to implement (ROOM T).

  Daniel Barlow doesn't know what fixed this, but observes that it
  doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T)
  in a fresh SBCL causes

    debugger invoked on a SB-INT:BUG in thread 5911:
        failed AVER: "(SAP= CURRENT END)"

  unless a GC has happened beforehand.

117:
  When the compiler inline expands functions, it may be that different
  kinds of return values are generated from different code branches.
  E.g. an inline expansion of POSITION generates integer results
  from one branch, and NIL results from another. When that inline
  expansion is used in a context where only one of those results
  is acceptable, e.g.
    (defun foo (x)
      (aref *a1* (position x *a2*)))
  and the compiler can't prove that the unacceptable branch is
  never taken, then bogus type mismatch warnings can be generated.
  If you need to suppress the type mismatch warnings, you can
  suppress the inline expansion,
    (defun foo (x)
      #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
      (aref *a1* (position x *a2*)))
  or, sometimes, suppress them by declaring the result to be of an
  appropriate type,
    (defun foo (x)
      (aref *a1* (the integer (position x *a2*))))

  This is not a new compiler problem in 0.7.0, but the new compiler
  transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
  more conspicuous. If you don't need performance from these functions,
  and the bogus warnings are a nuisance for you, you can return to
  your pre-0.7.0 state of grace with
    #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..

  (see also bug 279)

124:
   As of version 0.pre7.14, SBCL's implementation of MACROLET makes
   the entire lexical environment at the point of MACROLET available
   in the bodies of the macroexpander functions. In particular, it
   allows the function bodies (which run at compile time) to try to
   access lexical variables (which are only defined at runtime).
   It doesn't even issue a warning, which is bad.

   The SBCL behavior arguably conforms to the ANSI spec (since the
   spec says that the behavior is undefined, ergo anything conforms).
   However, it would be better to issue a compile-time error.
   Unfortunately I (WHN) don't see any simple way to detect this
   condition in order to issue such an error, so for the meantime
   SBCL just does this weird broken "conforming" thing.

   The ANSI standard says, in the definition of the special operator
   MACROLET,
       The macro-expansion functions defined by MACROLET are defined
       in the lexical environment in which the MACROLET form appears.
       Declarations and MACROLET and SYMBOL-MACROLET definitions affect
       the local macro definitions in a MACROLET, but the consequences
       are undefined if the local macro definitions reference any
       local variable or function bindings that are visible in that
       lexical environment.
   Then it seems to contradict itself by giving the example
(defun foo (x flag)
(macrolet ((fudge (z)
;The parameters x and flag are not accessible
; at this point; a reference to flag would be to
; the global variable of that name.
` (if flag (* ,z ,z) ,z)))
;The parameters x and flag are accessible here.
(+ x
(fudge x)
(fudge (+ x 1)))))
   The comment "a reference to flag would be to the global variable
   of the same name" sounds like good behavior for the system to have.
   but actual specification quoted above says that the actual behavior
   is undefined.

   (Since 0.7.8.23 macroexpanders are defined in a restricted version
   of the lexical environment, containing no lexical variables and
   functions, which seems to conform to ANSI and CLtL2, but signalling
   a STYLE-WARNING for references to variables similar to locals might
   be a good thing.)

125:
   (as reported by Gabe Garza on cmucl-help 2001-09-21)
(defvar *tmp* 3)
(defun test-pred (x y)
(eq x y))
(defun test-case ()
(let* ((x *tmp*)
(func (lambda () x)))
(print (eq func func))
(print (test-pred func func))
(delete func (list func))))
   Now calling (TEST-CASE) gives output
     NIL
     NIL
     (#<FUNCTION {500A9EF9}>)
   Evidently Python thinks of the lambda as a code transformation so
   much that it forgets that it's also an object.

135:
  Ideally, uninterning a symbol would allow it, and its associated
  FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
  at least as of sbcl-0.7.0, this isn't the case. Information about
  FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
  essentially in ordinary (non-weak) hash tables keyed by symbols.
  Thus, once a system has an entry in this system, it tends to live
  forever, even when it is uninterned and all other references to it
  are lost.

143:
  (reported by Jesse Bouwman 2001-10-24 through the unfortunately
  prominent SourceForge web/db bug tracking system, which is
  unfortunately not a reliable way to get a timely response from
  the SBCL maintainers)
      In the course of trying to build a test case for an
    application error, I encountered this behavior:
      If you start up sbcl, and then lay on CTRL-C for a
    minute or two, the lisp process will eventually say:
         %PRIMITIVE HALT called; the party is over.
    and throw you into the monitor. If I start up lisp,
    attach to the process with strace, and then do the same
    (abusive) thing, I get instead:
         access failure in heap page not marked as write-protected
    and the monitor again. I don't know enough to have the
    faintest idea of what is going on here.
      This is with sbcl 6.12, uname -a reports:
         Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown
  I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
  under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
  it took more than two minutes (but less than five) for me.

145:
  a.
  ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
  FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
  COMPLEX implementation didn't deal with this, and hasn't been
  upgraded to do so. (This doesn't seem to be a high priority
  conformance problem, since seems hard to construct useful code
  where it matters.)

  b. (fixed in 0.8.3.43)

146:
  Floating point errors are reported poorly. E.g. on x86 OpenBSD
  with sbcl-0.7.1,
* (expt 2.0 12777)
debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
No traps are enabled? How can this be?
  It should be possible to be much more specific (overflow, division
  by zero, etc.) and of course the "How can this be?" should be fixable.

  See also bugs #45.c and #183

162:
  (reported by Robert E. Brown 2002-04-16)
  When a function is called with too few arguments, causing the
  debugger to be entered, the uninitialized slots in the bad call frame
  seem to cause GCish problems, being interpreted as tagged data even
  though they're not. In particular, executing ROOM in the
  debugger at that point causes AVER failures:
    * (machine-type)
    "X86"
    * (lisp-implementation-version)
    "0.7.2.12"
    * (typep 10)
    ...
    0] (room)
    ...
    failed AVER: "(SAP= CURRENT END)"
  (Christophe Rhodes reports that this doesn't occur on the SPARC, which
  isn't too surprising since there are many differences in stack
  implementation and GC conservatism between the X86 and other ports.)

  This is probably the same bug as 216

173:
  The compiler sometimes tries to constant-fold expressions before
  it checks to see whether they can be reached. This can lead to
  bogus warnings about errors in the constant folding, e.g. in code
  like
    (WHEN X
      (WRITE-STRING (> X 0) "+" "0"))
  compiled in a context where the compiler can prove that X is NIL,
  and the compiler complains that (> X 0) causes a type error because
  NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
  caused a full WARNING, which made the bug really annoying because then
  COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
  code. Since then the warning has been downgraded to STYLE-WARNING,
  so it's still a bug but at least it's a little less annoying.

183: "IEEE floating point issues"
  Even where floating point handling is being dealt with relatively
  well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
  accrued-exceptions and current-exceptions part of the fp control
  word don't seem to bear much relation to reality. E.g. on
  SPARC/SunOS:
  * (/ 1.0 0.0)

  debugger invoked on condition of type DIVISION-BY-ZERO:
    arithmetic error DIVISION-BY-ZERO signalled
  0] (sb-vm::get-floating-point-modes)

  (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
          :ROUNDING-MODE :NEAREST
          :CURRENT-EXCEPTIONS NIL
          :ACCRUED-EXCEPTIONS (:INEXACT)
          :FAST-MODE NIL)
  0] abort
  * (sb-vm::get-floating-point-modes)
  (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
          :ROUNDING-MODE :NEAREST
          :CURRENT-EXCEPTIONS (:INEXACT)
          :ACCRUED-EXCEPTIONS (:INEXACT)
          :FAST-MODE NIL)

188: "compiler performance fiasco involving type inference and UNION-TYPE"
    (time (compile
           nil
           '(lambda ()
             (declare (optimize (safety 3)))
             (declare (optimize (compilation-speed 2)))
             (declare (optimize (speed 1) (debug 1) (space 1)))
             (let ((start 4))
               (declare (type (integer 0) start))
               (print (incf start 22))
               (print (incf start 26))
               (print (incf start 28)))
             (let ((start 6))
               (declare (type (integer 0) start))
               (print (incf start 22))
               (print (incf start 26)))
             (let ((start 10))
               (declare (type (integer 0) start))
               (print (incf start 22))
               (print (incf start 26))))))

  This example could be solved with clever enough constraint
  propagation or with SSA, but consider

    (let ((x 0))
      (loop (incf x 2)))

  The careful type of X is {2k} :-(. Is it really important to be
  able to work with unions of many intervals?

191: "Miscellaneous PCL deficiencies"
  (reported by Alexey Dejneka sbcl-devel 2002-08-04)
  a. DEFCLASS does not inform the compiler about generated
     functions. Compiling a file with
       (DEFCLASS A-CLASS ()
         ((A-CLASS-X)))
       (DEFUN A-CLASS-X (A)
         (WITH-SLOTS (A-CLASS-X) A
           A-CLASS-X))
     results in a STYLE-WARNING:
       undefined-function
         SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|

     APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
     Mai points out that the declamation of functions is in fact
     incorrect in some cases (most notably for structure
     classes). This means that at present erroneous attempts to use
     WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
     won't get the corresponding STYLE-WARNING.
  c. (fixed in 0.8.4.23)

201: "Incautious type inference from compound types"
  a. (reported by APD sbcl-devel 2002-09-17)
    (DEFUN FOO (X)
      (LET ((Y (CAR (THE (CONS INTEGER *) X))))
        (SETF (CAR X) NIL)
        (FORMAT NIL "~S IS ~S, Y = ~S"
                (CAR X)
                (TYPECASE (CAR X)
                  (INTEGER 'INTEGER)
                  (T '(NOT INTEGER)))
                Y)))

    (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"

  b.
    * (defun foo (x)
        (declare (type (array * (4 4)) x))
        (let ((y x))
          (setq x (make-array '(4 4)))
          (adjust-array y '(3 5))
          (= (array-dimension y 0) (eval `(array-dimension ,y 0)))))
    FOO
    * (foo (make-array '(4 4) :adjustable t))
    NIL

205: "environment issues in cross compiler"
  (These bugs have no impact on user code, but should be fixed or
  documented.)
  a. Macroexpanders introduced with MACROLET are defined in the null
     lexical environment.
  b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
     the null lexical environment.
  c. The cross-compiler cannot inline functions defined in a non-null
     lexical environment.

206: ":SB-FLUID feature broken"
  (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
  Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
  the build.

207: "poorly distributed SXHASH results for compound data"
  SBCL's SXHASH could probably try a little harder. ANSI: "the
  intent is that an implementation should make a good-faith
  effort to produce hash-codes that are well distributed
  within the range of non-negative fixnums". But
(let ((hits (make-hash-table)))
(dotimes (i 16)
(dotimes (j 16)
(let* ((ij (cons i j))
                     (newlist (push ij (gethash (sxhash ij) hits))))
(when (cdr newlist)
(format t "~&collision: ~S~%" newlist))))))
  reports lots of collisions in sbcl-0.7.8. A stronger MIX function
  would be an obvious way of fix. Maybe it would be acceptably efficient
  to redo MIX using a lookup into a 256-entry s-box containing
  29-bit pseudorandom numbers?

211: "keywords processing"
  a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
     number of keyword arguments.
  e. Compiling

      (flet ((foo (&key y) (list y)))
        (list (foo :y 1 :y 2)))

     issues confusing message

       ; in: LAMBDA NIL
       ; (FOO :Y 1 :Y 2)
       ;
       ; caught STYLE-WARNING:
       ; The variable #:G15 is defined but never used.

212: "Sequence functions and circular arguments"
  COERCE, MERGE and CONCATENATE go into an infinite loop when given
  circular arguments; it would be good for the user if they could be
  given an error instead (ANSI 17.1.1 allows this behaviour on the part
  of the implementation, as conforming code cannot give non-proper
  sequences to these functions. MAP also has this problem (and
  solution), though arguably the convenience of being able to do
    (MAP 'LIST '+ FOO '#1=(1 . #1#))
  might be classed as more important (though signalling an error when
  all of the arguments are circular is probably desireable).

213: "Sequence functions and type checking"
  b. MAP, when given a type argument that is SUBTYPEP LIST, does not
     check that it will return a sequence of the given type. Fixing
     it along the same lines as the others (cf. work done around
     sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
     entirely straightforward.
  c. All of these functions will silently accept a type of the form
       (CONS INTEGER *)
     whether or not the return value is of this type. This is
     probably permitted by ANSI (see "Exceptional Situations" under
     ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
     know about this escape clause, so code of the form
       (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
     can erroneously return T.

215: ":TEST-NOT handling by functions"
  a. FIND and POSITION currently signal errors when given non-NIL for
     both their :TEST and (deprecated) :TEST-NOT arguments, but by
     ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
     means that the effect is "unpredictable but harmless". It's not
     clear what that actually means; it may preclude conforming
     implementations from signalling errors.
  b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
     when conflict occurs. As a quality of implementation issue, it
     might be preferable to treat :TEST and :TEST-NOT as being in some
     sense the same &KEY, and effectively take the first test function in
     the argument list.
  c. Again, a quality of implementation issue: it would be good to issue a
     STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
     WARNING for calls with both :TEST and :TEST-NOT; possibly this
     latter should be WARNed about at execute-time too.

216: "debugger confused by frames with invalid number of arguments"
  In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
  leaves the system confused, enough so that (QUIT) no longer works.
  It's as though the process of working with the uninitialized slot in
  the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
  not be the actual problem. (CMU CL 18c doesn't have problems with this.)

  This is probably the same bug as 162

217: "Bad type operations with FUNCTION types"
  In sbcl.0.7.7:

    * (values-type-union (specifier-type '(function (base-char)))
                         (specifier-type '(function (integer))))

    #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>

  It causes insertion of wrong type assertions into generated
  code. E.g.

    (defun foo (x s)
      (let ((f (etypecase x
                 (character #'write-char)
                 (integer #'write-byte))))
        (funcall f x s)
        (etypecase x
          (character (write-char x s))
          (integer (write-byte x s)))))

   Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.

  (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
  produce invalid code, but type checking is not accurate.)

233: bugs in constraint propagation
  b.
  (declaim (optimize (speed 2) (safety 3)))
  (defun foo (x y)
    (if (typep (prog1 x (setq x y)) 'double-float)
        (+ x 1d0)
        (+ x 2)))
  (foo 1d0 5) => segmentation violation

235: "type system and inline expansion"
  a.
  (declaim (ftype (function (cons) number) acc))
  (declaim (inline acc))
  (defun acc (c)
    (the number (car c)))

  (defun foo (x y)
    (values (locally (declare (optimize (safety 0)))
              (acc x))
            (locally (declare (optimize (safety 3)))
              (acc y))))

  (foo '(nil) '(t)) => NIL, T.

237: "Environment arguments to type functions"
  a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
     UPGRADED-COMPLEX-PART-TYPE now have an optional environment
     argument, but they ignore it completely. This is almost
     certainly not correct.
  b. Also, the compiler's optimizers for TYPEP have not been informed
     about the new argument; consequently, they will not transform
     calls of the form (TYPEP 1 'INTEGER NIL), even though this is
     just as optimizeable as (TYPEP 1 'INTEGER).

238: "REPL compiler overenthusiasm for CLOS code"
  From the REPL,
    * (defclass foo () ())
    * (defmethod bar ((x foo) (foo foo)) (call-next-method))
  causes approximately 100 lines of code deletion notes. Some
  discussion on this issue happened under the title 'Three "interesting"
  bugs in PCL', resulting in a fix for this oververbosity from the
  compiler proper; however, the problem persists in the interactor
  because the notion of original source is not preserved: for the
  compiler, the original source of the above expression is (DEFMETHOD
  BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
  compiler gets its hands on the code needing compilation from the REPL,
  it has been macroexpanded several times.

  A symptom of the same underlying problem, reported by Tony Martinez:
    * (handler-case
        (with-input-from-string (*query-io* " no")
          (yes-or-no-p))
      (simple-type-error () 'error))
    ; in: LAMBDA NIL
    ; (SB-KERNEL:FLOAT-WAIT)
    ;
    ; note: deleting unreachable code
    ; compilation unit finished
    ; printed 1 note

242: "WRITE-SEQUENCE suboptimality"
  (observed from clx performance)
  In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
  (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
  (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
  rather than writing the sequence in one go, leading to severe
  performance degradation.

243: "STYLE-WARNING overenthusiasm for unused variables"
  (observed from clx compilation)
  In sbcl-0.7.14, in the presence of the macros
    (DEFMACRO FOO (X) `(BAR ,X))
    (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
  somewhat surprising style warnings are emitted for
    (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
  ; in: LAMBDA (Y)
  ; (LAMBDA (Y) (FOO Y))
  ;
  ; caught STYLE-WARNING:
  ; The variable Y is defined but never used.

245: bugs in disassembler
  b. On X86 operand size prefix is not recognized.

251:
  (defun foo (&key (a :x))
    (declare (fixnum a))
    a)

  does not cause a warning. (BTW: old SBCL issued a warning, but for a
  function, which was never called!)

256:
  Compiler does not emit warnings for

  a. (lambda () (svref (make-array 8 :adjustable t) 1))

  b. (lambda (x)
       (list (let ((y (the real x)))
               (unless (floatp y) (error ""))
               y)
             (integer-length x)))

  c. (lambda (x)
       (declare (optimize (debug 0)))
       (declare (type vector x))
       (list (fill-pointer x)
             (svref x 1)))

257:
  Complex array type does not have corresponding type specifier.

  This is a problem because the compiler emits optimization notes when
  you use a non-simple array, and without a type specifier for hairy
  array types, there's no good way to tell it you're doing it
  intentionally so that it should shut up and just compile the code.

  Another problem is confusing error message "asserted type ARRAY
  conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
  compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).

  The last problem is that when type assertions are converted to type
  checks, types are represented with type specifiers, so we could lose
  complex attribute. (Now this is probably not important, because
  currently checks for complex arrays seem to be performed by
  callees.)

259:
  (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
  warning. Analogous cases with the index and length being equal and
  greater than 0 are warned for; the problem here seems to be that the
  type required for an array reference of this type is (INTEGER 0 (0))
  which is canonicalized to NIL.

260:
  a.
  (let* ((s (gensym))
         (t1 (specifier-type s)))
    (eval `(defstruct ,s))
    (type= t1 (specifier-type s)))
  => NIL, NIL

  (fixed in 0.8.1.24)

  b. The same for CSUBTYPEP.

262: "yet another bug in inline expansion of local functions"
  Compiler fails on

    (defun foo (x y)
      (declare (integer x y))
      (+ (block nil
            (flet ((xyz (u)
                     (declare (integer u))
                     (if (> (1+ (the unsigned-byte u)) 0)
                         (+ 1 u)
                         (return (+ 38 (cos (/ u 78)))))))
              (declare (inline xyz))
              (return-from foo
                (* (funcall (eval #'xyz) x)
                   (if (> x 30)
                       (funcall (if (> x 5) #'xyz #'identity)
                                (+ x 13))
                       38)))))
         (sin (* x y))))

  Urgh... It's time to write IR1-copier.

266:
  David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
  behaviour of streams with element-type (SIGNED-BYTE 8). The patch
  looks reasonable, if not obviously correct; however, it caused the
  PPC/Linux port to segfault during warm-init while loading
  src/pcl/std-class.fasl. A workaround patch was made, but it would
  be nice to understand why the first patch caused problems, and to
  fix the cause if possible.

268: "wrong free declaration scope"
  The following code must signal type error:

    (locally (declare (optimize (safety 3)))
      (flet ((foo (x &optional (y (car x)))
               (declare (optimize (safety 0)))
               (list x y)))
        (funcall (eval #'foo) 1)))

270:
  In the following function constraint propagator optimizes nothing:

    (defun foo (x)
      (declare (integer x))
      (declare (optimize speed))
      (typecase x
        (fixnum "hala")
        (fixnum "buba")
        (bignum "hip")
        (t "zuz")))

273:
  Compilation of the following two forms causes "X is unbound" error:

    (symbol-macrolet ((x pi))
      (macrolet ((foo (y) (+ x y)))
        (declaim (inline bar))
        (defun bar (z)
          (* z (foo 4)))))
    (defun quux (z)
      (bar z))

  (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)

274:
  CLHS says that type declaration of a symbol macro should not affect
  its expansion, but in SBCL it does. (If you like magic and want to
  fix it, don't forget to change all uses of MACROEXPAND to
  MACROEXPAND*.)

275:
  The following code (taken from CLOCC) takes a lot of time to compile:

    (defun foo (n)
      (declare (type (integer 0 #.large-constant) n))
      (expt 1/10 n))

  (fixed in 0.8.2.51, but a test case would be good)

278:
  a.
    (defun foo ()
      (declare (optimize speed))
      (loop for i of-type (integer 0) from 0 by 2 below 10
            collect i))

  uses generic arithmetic.

  b. (fixed in 0.8.3.6)

279: type propagation error -- correctly inferred type goes astray?
  In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
       The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
       &OPTIONAL), not a (INTEGER 1 536870911)
  is emitted when compiling this file:
    (declaim (ftype (function ((integer 0 #.most-positive-fixnum))
                              (integer #.most-negative-fixnum 0))
                    foo))
    (defun foo (x)
      (- x))
    (defun bar (x)
      (let* (;; Uncomment this for a type mismatch warning indicating
             ;; that the type of (FOO X) is correctly understood.
             #+nil (fs-foo (float-sign (foo x)))
                   ;; Uncomment this for a type mismatch warning
                   ;; indicating that the type of (ABS (FOO X)) is
                   ;; correctly understood.
             #+nil (fs-abs-foo (float-sign (abs (foo x))))
             ;; something wrong with this one though
             (abs-foo (abs (foo x))))
        (declare (type (integer 1 100) abs-foo))
        (print abs-foo)))

 (see also bug 117)

281: COMPUTE-EFFECTIVE-METHOD error signalling.
  (slightly obscured by a non-0 default value for
   SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
  It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
  when it finds a method with invalid qualifiers. However, it
  shouldn't signal errors when any such methods are not applicable to
  the particular call being evaluated, and certainly it shouldn't when
  simply precomputing effective methods that may never be called.
  (setf sb-pcl::*max-emf-precompute-methods* 0)
  (defgeneric foo (x)
    (:method-combination +)
    (:method ((x symbol)) 1)
    (:method + ((x number)) x))
  (foo 1) -> ERROR, but should simply return 1

  The issue seems to be that construction of a discriminating function
  calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.

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
  bug instead of creating new ones

    localtime() - called for timezone calculations in code/time.lisp

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
  parts of the system. See doc/internals/notes/threading-specials

286: "recursive known functions"
  Self-call recognition conflicts with known function
  recognition. Currently cross compiler and target COMPILE do not
  recognize recursion, and in target compiler it can be disabled. We
  can always disable it for known functions with RECURSIVE attribute,
  but there remains a possibility of a function with a
  (tail)-recursive simplification pass and transforms/VOPs for base
  cases.

287: PPC/Linux miscompilation or corruption in first GC
  When the runtime is compiled with -O3 on certain PPC/Linux machines, a
  segmentation fault is reported at the point of first triggered GC,
  during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround,
  the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely
  that this merely obscures, not solves, the underlying problem; as and when
  underlying problems are fixed, it would be worth trying again to provoke
  this problem.

288: fundamental cross-compilation issues (from old UGLINESS file)
  Using host floating point numbers to represent target floating point
  numbers, or host characters to represent target characters, is
  theoretically shaky. (The characters are OK as long as the characters
  are in the ANSI-guaranteed character set, though, so they aren't a
  real problem as long as the sources don't need anything but that;
  the floats are a real problem.)

289: "type checking and source-transforms"
  a.
    (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
  signals type error.

  Our policy is to check argument types at the moment of a call. It
  disagrees with ANSI, which says that type assertions are put
  immediately onto argument expressions, but is easier to implement in
  IR1 and is more compatible to type inference, inline expansion,
  etc. IR1-transforms automatically keep this policy, but source
  transforms for associative functions (such as +), being applied
  during IR1-convertion, do not. It may be tolerable for direct calls
  (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.

  b. Another aspect of this problem is efficiency. [x y + z +]
  requires less registers than [x y z + +]. This transformation is
  currently performed with source transforms, but it would be good to
  also perform it in IR1 optimization phase.

290: Alpha floating point and denormalized traps
  In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
  hardware or kernel deficiency: the status of the enable/disable
  denormalized-float traps bit seems to be ambiguous; by the time we
  get to os_restore_fp_control after a trap, denormalized traps seem
  to be enabled. Since we don't want a trap every time someone uses a
  denormalized float, in general, we mask out that bit when we restore
  the control word; however, this clobbers any change the user might
  have made.

296:
  (reported by Adam Warner, sbcl-devel 2003-09-23)

  The --load toplevel argument does not perform any sanitization of its
  argument. As a result, files with Lisp pathname pattern characters
  (#\* or #\?, for instance) or quotation marks can cause the system
  to perform arbitrary behaviour.

297:
  LOOP with non-constant arithmetic step clauses suffers from overzealous
  type constraint: code of the form
    (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
  compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
  (0))). However, an integral value of X should be legal, because
  successive adds of integers to double-floats produces double-floats,
  so none of the type restrictions in the code is violated.

300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
  argument type only after having read a character. This is caused
  with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
  exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
  less error prone to have EXPLICIT-CHECK be a local declaration,
  being put into the definition, instead of an attribute being kept in
  a separate file; maybe also put it into SB-EXT?

301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
     in NOTE-ASSUMED-TYPES
  In sbcl-0.8.7.32, compiling the file
(defun foo (x y)
(declare (type integer x))
(declare (type (vector (or hash-table bit)) y))
(bletch 2 y))
(defun bar (x y)
(declare (type integer x))
(declare (type (simple-array base (2)) y))
(bletch 1 y))
  gives the error
    failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"

302: Undefined type messes up DATA-VECTOR-REF expansion.
  Compiling this file
    (defun dis (s ei x y)
      (declare (type (simple-array function (2)) s) (type ei ei))
      (funcall (aref s ei) x y))
  on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled:
    full call to SB-KERNEL:DATA-VECTOR-REF

303: "nonlinear LVARs" (aka MISC.293)
    (defun buu (x)
      (multiple-value-call #'list
        (block foo
          (multiple-value-prog1
              (eval '(values :a :b :c))
            (catch 'bar
              (if (> x 0)
                  (return-from foo
                    (eval `(if (> ,x 1)
                               1
                               (throw 'bar (values 3 4)))))))))))

  (BUU 1) returns garbage.

  The problem is that both EVALs sequentially write to the same LVAR.

305:
  (Reported by Dave Roberts.)
  Local INLINE/NOTINLINE declaration removes local FTYPE declaration:

    (defun quux (x)
      (declare (ftype (function () (integer 0 10)) fee)
               (inline fee))
      (1+ (fee)))

  uses generic arithmetic with INLINE and fixnum without.

306: "Imprecise unions of array types"
  a.(defun foo (x)
      (declare (optimize speed)
               (type (or (array cons) (array vector)) x))
      (elt (aref x 0) 0))
    (foo #((0))) => TYPE-ERROR

  relatedly,

  b.(subtypep
     'array
     `(or
       ,@(loop for x across sb-vm:*specialized-array-element-type-properties*
               collect `(array ,(sb-vm:saetp-specifier x)))))
    => NIL, T (when it should be T, T)

308: "Characters without names"
    (reported by Bruno Haible sbcl-devel "character names are missing"
    2004-04-19)
  (graphic-char-p (code-char 255))
  => NIL
  (char-name (code-char 255))
  => NIL

  SBCL is unsure of what to do about characters with codes in the
  range 128-255. Currently they are treated as non-graphic, but don't
  have names, which is not compliant with the standard. Various fixes
  are possible, such as
  * giving them names such as NON-ASCII-128;
  * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular);
  * making the characters graphic (makes a certain amount of sense);
  * biting the bullet and implementing Unicode (probably quite hard).

309: "Dubious values for implementation limits"
    (reported by Bruno Haible sbcl-devel "Incorrect value of
    multiple-values-limit" 2004-04-19)
  (values-list (make-list 1000000)), on x86/linux, signals a stack
  exhaustion condition, despite MULTIPLE-VALUES-LIMIT being
  significantly larger than 1000000. There are probably similar
  dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp
  around the same time regarding a call to LIST on sparc with 1000
  arguments) and other implementation limit constants.

311: "Tokeniser not thread-safe"
    (see also Robert Marlow sbcl-help "Multi threaded read chucking a
    spak" 2004-04-19)
  The tokenizer's use of *read-buffer* and *read-buffer-length* causes
  spurious errors should two threads attempt to tokenise at the same
  time.

314: "LOOP :INITIALLY clauses and scope of initializers"
  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
  test suite, originally by Thomas F. Burdick.
    ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
    ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is
    ;; initialized to the result of evaluating form1. 6.1.7.2 says that
    ;; initially clauses are evaluated in the loop prologue, which precedes all
    ;; loop code except for the initial settings provided by with, for, or as.
    (loop :for x = 0 :then (1+ x)
          :for y = (1+ x) :then (ash y 1)
          :for z :across #(1 3 9 27 81 243)
          :for w = (+ x y z)
          :initially (assert (zerop x)) :initially (assert (= 2 w))
          :until (>= w 100) :collect w)
    Expected: (2 6 15 38)
    Got: ERROR

317: "FORMAT of floating point numbers"
  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
  test suite.
    (format nil "~1F" 10) => "0." ; "10." expected
    (format nil "~0F" 10) => "0." ; "10." expected
    (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
  it would be nice if whatever fixed this also untangled the two
  competing implementations of floating point printing (Steele and
  White, and Burger and Dybvig) present in src/code/print.lisp

318: "stack overflow in compiler warning with redefined class"
  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
  test suite.
    (setq *print-pretty* nil)
    (defstruct foo a)
    (setf (find-class 'foo) nil)
    (defstruct foo slot-1)
  gives
    ...#<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTUREControl stack guard page temporarily disabled: proceed with caution
  (it's not really clear what it should give: is (SETF FIND-CLASS)
  meant to be enough to delete structure classes from the system?
  Giving a stack overflow is definitely suboptimal, though.)

319: "backquote with comma inside array"
  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
  test suite.
    (read-from-string "`#1A(1 2 ,(+ 2 2) 4)")
  gives
    #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
  which probably isn't intentional.

323: "REPLACE, BIT-BASH and large strings"
  The transform for REPLACE on simple-base-strings uses BIT-BASH, which
  at present has an upper limit in size. Consequently, in sbcl-0.8.10
    (defun foo ()
      (declare (optimize speed (safety 1)))
      (let ((x (make-string 140000000))
            (y (make-string 140000000)))
        (length (replace x y))))
    (foo)
  gives
    debugger invoked on a TYPE-ERROR in thread 2412:
      The value 1120000000 is not of type (MOD 536870911).
  (see also "more and better sequence transforms" sbcl-devel 2004-05-10)

324: "STREAMs and :ELEMENT-TYPE with large bytesize"
  In theory, (open foo :element-type '(unsigned-byte <x>)) should work
  for all positive integral <x>. At present, it only works for <x> up
  to about 1024 (and similarly for signed-byte), so
    (open "/dev/zero" :element-type '(unsigned-byte 1025))
  gives an error in sbcl-0.8.10.

325: "CLOSE :ABORT T on supeseding streams"
  Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
  file on disk, even if one existed before opening.

  The illegality of this is not crystal clear, as the ANSI dictionary
  entry for CLOSE says that when :ABORT is T superseded files are not
  superseded (ie. the original should be restored), whereas the OPEN
  entry says about :IF-EXISTS :SUPERSEDE "If possible, the
  implementation should not destroy the old file until the new stream
  is closed." -- implying that even though undesirable, early deletion
  is legal. Restoring the original would none the less be the polite
  thing to do.

326: "*PRINT-CIRCLE* crosstalk between streams"
  In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be
  mixed between streams when output operations are intermingled closely
  enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the
  test case below), so that e.g. the references #2# appears on a stream
  with no preceding #2= on that stream to define it (because the #2= was
  sent to another stream).
    (cl:in-package :cl-user)
    (defstruct foo index)
    (defparameter *foo* (make-foo :index 4))
    (defstruct bar)
    (defparameter *bar* (make-bar))
    (defparameter *tangle* (list *foo* *bar* *foo*))
    (defmethod print-object ((foo foo) stream)
      (let ((index (foo-index foo)))
        (format *trace-output*
     "~&-$- emitting FOO ~D, ambient *BAR*=~S~%"
     index *bar*)
        (format stream "[FOO ~D]" index))
      foo)
    (let ((tsos (make-string-output-stream))
          (ssos (make-string-output-stream)))
      (let ((*print-circle* t)
     (*trace-output* tsos)
     (*standard-output* ssos))
        (prin1 *tangle* *standard-output*))
      (let ((string (get-output-stream-string ssos)))
        (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
          ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
          (error "oops: ~S" string)))))
  It might be straightforward to fix this by turning the
  *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
  per-stream slots, but (1) it would probably be sort of messy faking
  up the special variable binding semantics using UNWIND-PROTECT and
  (2) it might be sort of a pain to test that no other bugs had been
  introduced.

328: "Profiling generic functions", transplanted from #241
  (from tonyms on #lisp IRC 2003-02-25)
  In sbcl-0.7.12.55, typing
    (defclass foo () ((bar :accessor foo-bar)))
    (profile foo-bar)
    (unintern 'foo-bar)
    (defclass foo () ((bar :accessor foo-bar)))
  gives the error message
    "#:FOO-BAR already names an ordinary function or a macro."

  Problem: when a generic function is profiled, it appears as an ordinary
  function to PCL. (Remembering the uninterned accessor is OK, as the
  redefinition must be able to remove old accessors from their generic
  functions.)

329: "Sequential class redefinition"
  reported by Bruno Haible:
   (defclass reactor () ((max-temp :initform 10000000)))
   (defvar *r1* (make-instance 'reactor))
   (defvar *r2* (make-instance 'reactor))
   (slot-value *r1* 'max-temp)
   (slot-value *r2* 'max-temp)
   (defclass reactor () ((uptime :initform 0)))
   (slot-value *r1* 'uptime)
   (defclass reactor () ((uptime :initform 0) (max-temp :initform 10000)))
   (slot-value *r1* 'max-temp) ; => 10000
   (slot-value *r2* 'max-temp) ; => 10000000 oops...

  Possible solution:
   The method effective when the wrapper is obsoleted can be saved
     in the wrapper, and then to update the instance just run through
     all the old wrappers in order from oldest to newest.

331: "lazy creation of CLOS classes for user-defined conditions"
    (defstruct foo)
    (defstruct (bar (:include foo)))
    (sb-mop:class-direct-subclasses (find-class 'foo))
  returns NIL, rather than a singleton list containing the BAR class.

332: "fasl stack inconsistency in structure redefinition"
  (reported by Tim Daly Jr sbcl-devel 2004-05-06)
  Even though structure redefinition is undefined by the standard, the
  following behaviour is suboptimal: running
    (defun stimulate-sbcl ()
      (let ((filename (format nil "/tmp/~A.lisp" (gensym))))
        ;;create a file which redefines a structure incompatibly
        (with-open-file (f filename :direction :output :if-exists :supersede)
          (print '(defstruct astruct foo) f)
          (print '(defstruct astruct foo bar) f))
        ;;compile and load the file, then invoke the continue restart on
        ;;the structure redefinition error
        (handler-bind ((error (lambda (c) (continue c))))
          (load (compile-file filename)))))
    (stimulate-sbcl)
  and choosing the CONTINUE restart yields the message
    debugger invoked on a SB-INT:BUG in thread 27726:
      fasl stack not empty when it should be

336: "slot-definitions must retain the generic functions of accessors"
  reported by Tony Martinez:
    (defclass foo () ((bar :reader foo-bar)))
    (defun foo-bar (x) x)
    (defclass foo () ((bar :reader get-bar))) ; => error, should work

  Note: just punting the accessor removal if the fdefinition
  is not a generic function is not enough:

   (defclass foo () ((bar :reader foo-bar)))
   (defvar *reader* #'foo-bar)
   (defun foo-bar (x) x)
   (defclass foo () ((bar :initform 'ok :reader get-bar)))
   (funcall *reader* (make-instance 'foo)) ; should be an error, since
                                           ; the method must be removed
                                           ; by the class redefinition

  Fixing this should also fix a subset of #328 -- update the
  description with a new test-case then.

337: MAKE-METHOD and user-defined method classes
  (reported by Bruno Haible sbcl-devel 2004-06-11)

  In the presence of

(defclass user-method (standard-method) (myslot))
(defmacro def-user-method (name &rest rest)
  (let* ((lambdalist-position (position-if #'listp rest))
         (qualifiers (subseq rest 0 lambdalist-position))
         (lambdalist (elt rest lambdalist-position))
         (body (subseq rest (+ lambdalist-position 1)))
         (required-part
          (subseq lambdalist 0 (or
                                (position-if
                                 (lambda (x) (member x lambda-list-keywords))
                                 lambdalist)
                                (length lambdalist))))
         (specializers (mapcar #'find-class
                               (mapcar (lambda (x) (if (consp x) (second x) t))
                                       required-part)))
         (unspecialized-required-part
          (mapcar (lambda (x) (if (consp x) (first x) x)) required-part))
         (unspecialized-lambdalist
          (append unspecialized-required-part
           (subseq lambdalist (length required-part)))))
    `(PROGN
       (ADD-METHOD #',name
         (MAKE-INSTANCE 'USER-METHOD
          :QUALIFIERS ',qualifiers
          :LAMBDA-LIST ',unspecialized-lambdalist
          :SPECIALIZERS ',specializers
          :FUNCTION
          (LAMBDA (ARGUMENTS NEXT-METHODS-LIST)
            (FLET ((NEXT-METHOD-P () NEXT-METHODS-LIST)
                   (CALL-NEXT-METHOD (&REST NEW-ARGUMENTS)
                     (UNLESS NEW-ARGUMENTS (SETQ NEW-ARGUMENTS ARGUMENTS))
                     (IF (NULL NEXT-METHODS-LIST)
                         (ERROR "no next method for arguments ~:S" ARGUMENTS)
                         (FUNCALL (SB-PCL:METHOD-FUNCTION
                                   (FIRST NEXT-METHODS-LIST))
                                  NEW-ARGUMENTS (REST NEXT-METHODS-LIST)))))
              (APPLY #'(LAMBDA ,unspecialized-lambdalist ,@body) ARGUMENTS)))))
       ',name)))

  (progn
    (defgeneric test-um03 (x))
    (defmethod test-um03 ((x integer))
      (list* 'integer x (not (null (next-method-p))) (call-next-method)))
    (def-user-method test-um03 ((x rational))
      (list* 'rational x (not (null (next-method-p))) (call-next-method)))
    (defmethod test-um03 ((x real))
      (list 'real x (not (null (next-method-p)))))
    (test-um03 17))
  works, but

  a.(progn
      (defgeneric test-um10 (x))
      (defmethod test-um10 ((x integer))
        (list* 'integer x (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um10 ((x rational))
        (list* 'rational x (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um10 ((x real))
        (list 'real x (not (null (next-method-p)))))
      (defmethod test-um10 :after ((x real)))
      (def-user-method test-um10 :around ((x integer))
        (list* 'around-integer x
         (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um10 :around ((x rational))
        (list* 'around-rational x
         (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um10 :around ((x real))
        (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
      (test-um10 17))
    fails with a type error, and

  b.(progn
      (defgeneric test-um12 (x))
      (defmethod test-um12 ((x integer))
        (list* 'integer x (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um12 ((x rational))
        (list* 'rational x (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um12 ((x real))
        (list 'real x (not (null (next-method-p)))))
      (defmethod test-um12 :after ((x real)))
      (defmethod test-um12 :around ((x integer))
        (list* 'around-integer x
         (not (null (next-method-p))) (call-next-method)))
      (defmethod test-um12 :around ((x rational))
        (list* 'around-rational x
         (not (null (next-method-p))) (call-next-method)))
      (def-user-method test-um12 :around ((x real))
        (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
      (test-um12 17))
    fails with NO-APPLICABLE-METHOD.

339: "DEFINE-METHOD-COMBINATION bugs"
  (reported by Bruno Haible via the clisp test suite)

  a. Syntax checking laxity (should produce errors):
     i. (define-method-combination foo :documentation :operator)
    ii. (define-method-combination foo :documentation nil)
   iii. (define-method-combination foo nil)
    iv. (define-method-combination foo nil nil
         (:arguments order &aux &key))
     v. (define-method-combination foo nil nil (:arguments &whole))
    vi. (define-method-combination foo nil nil (:generic-function))
   vii. (define-method-combination foo nil nil (:generic-function bar baz))
  viii. (define-method-combination foo nil nil (:generic-function (bar)))
    ix. (define-method-combination foo nil ((3)))
     x. (define-method-combination foo nil ((a)))

  b. define-method-combination arguments lambda list badness
     i. &aux args are currently unsupported;
    ii. default values of &optional and &key arguments are ignored;
   iii. supplied-p variables for &optional and &key arguments are not
        bound.

  c. qualifier matching incorrect
  (progn
    (define-method-combination mc27 ()
        ((normal ())
         (ignored (:ignore :unused)))
      `(list 'result
             ,@(mapcar #'(lambda (method) `(call-method ,method)) normal)))
    (defgeneric test-mc27 (x)
      (:method-combination mc27)
      (:method :ignore ((x number)) (/ 0)))
    (test-mc27 7))

  should signal an invalid-method-error, as the :IGNORE (NUMBER)
  method is applicable, and yet matches neither of the method group
  qualifier patterns.

340: SETF of VALUES using too many values
  (fixed in sbcl-0.8.12.10)

341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
  (from Paul Dietz' test suite)

  CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though
  that's slightly different) states that these functions perform
  circular and shared structure detection on their object. Therefore,

  a.(let ((*print-circle* t))
      (pprint-linear *standard-output* (let ((x '(a))) (list x x))))
    should print "(#1=(A) #1#)"

  b.(let ((*print-circle* t))
      (pprint-linear *standard-output*
                     (let ((x (cons nil nil))) (setf (cdr x) x) x)))
    should print "#1=(NIL . #1#)"

  (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as
  suggested by the suggested implementation of PPRINT-TABULAR)

342: PPRINT-TABULAR / PPRINT-LOGICAL-BLOCK logical block start position
  The logical block introduced by PPRINT-LOGICAL-BLOCK should not
  include the prefix, so that
    (pprint-tabular *standard-output* '(1 2 3) t nil 2)
  should print
  "(1 2 3)" rather than "(1 2 3)".

343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
  Even the simplest possible overriding of
  COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
  as "canonical", does not work:
    (defclass my-generic-function (standard-generic-function) ()
      (:metaclass funcallable-standard-class))
    (defmethod compute-discriminating-function ((gf my-generic-function))
      (let ((dfun (call-next-method)))
        (lambda (&rest args)
          (apply dfun args))))
    (defgeneric foo (x)
      (:generic-function-class my-generic-function))
    (defmethod foo (x) (+ x x))
    (foo 5)
  signals an error. This error is the same even if the LAMBDA is
  replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)). Maybe the
  SET-FUNCALLABLE-INSTANCE-FUN scary stuff in
  src/code/target-defstruct.lisp is broken? This seems to be broken
  in CMUCL 18e, so it's not caused by a recent change.

344: more (?) ROOM T problems (possibly part of bug 108)
  In sbcl-0.8.12.51, and off and on leading up to it, the
  SB!VM:MEMORY-USAGE operations in ROOM T caused
unhandled condition (of type SB-INT:BUG):
failed AVER: "(SAP= CURRENT END)"
  Several clever people have taken a shot at this without fixing
  it; this time around (before sbcl-0.8.13 release) I (WHN) just
  commented out the SB!VM:MEMORY-USAGE calls until someone figures
  out how to make them work reliably with the rest of the GC.
Something went wrong with that request. Please try again.