1
2 09/21/87 lisp
3 Known errors in the current release of lisp.
4 # Associated TR's
5 Description
6
7 34 phx20769
8 // x 1 and - x 0 are optimized by p1sysred and p1redcomm into //
9 x and - x, respectively, but these are not equivalent forms.
10
11 33 phx19999
12 It is possible for Lisp character strings to be relocated by garbage
13 collection after pointers to them have been put into argument lists
14 when calling PL/I subroutines defined with defpl1, causing strings of
15 zeroes to be passed instead of the correct strings. Calls that pass
16 several long strings are most likely to evoke this error, because they
17 tend to cause garbage collection when making copies of the strings for
18 the call so that the callee cannot write directly into the original
19 Lisp string because they are immutable.
20
21 32 phx19983
22 The *catch macro only allows one body form, when it should allow any
23 number.
24
25 31 phx19698
26 "numberp" returns t if the argument is a system-subr.
27
28 30 phx19568
29 DEFSETF expands to code that uses destructuring LET, but setf.incl.lisp
30 does not make sure that lisp_destructuring_let_ is loaded. It would
31 also be nice if it loaded backquote, as that is usually necessary;
32 however, the programmer knows whether he is using this so can be
33 expected to load it himself if necessary. It would be really nice if
34 these modules were only loaded if DEFSETF were used, as most uses of
35 setf.incl.lisp are probably only for uses of SETF, which doesn't
36 require destructuring LET or backquote.
37
38 29 phx19567
39 The syntax of DEFSETF does not agree with the definition in the MIT/LCS
40 Maclisp Manual. It is more like the Common Lisp version probably
41 exactly like the Zetalisp version. The syntax is
42 DEFSETF function lambda-list value-var . body
43
44 28 phx19561
45 SETF can generate code that calls LDB and DPB, but it doesn't guarantee
46 that these functions will be defined at runtime they are defined in
47 the "runtime" library module.
48
49 27 phx19560
50 The "runtime" library package doesn't sstatus feature runtime.
51
52 25 phx04264
53 The "fix" function returns 0 for arguments between -1.0 and 0.0
54 exclusive, but it should return -1.
55
56 24 phx19444
57 Lisp looks for the start_up.lisp in the default wdir, rather than in
58 the homedir as stated in lisp.info.
59
60 21 phx19070
61 The interpreter doesn't complain about changing the value of the
62 variable "t".
63
64 20 phx19018
65 The "tyi" function masks off the high-order 2 bits. This occurs a few
66 lines after "rdinch" in lisp_reader_alm_.alm. There are also a number
67 of problems like this in lisp_reader_.pl1. In general, Lisp is very
68 inconsistent in its support of characters above 127. in symbol names;
69 there are even places in lisp_reader_ where characters above 127 are
70 used as special markers.
71
72 19 phx19017
73 "maknam" and "implode" complain if fixnums in the input list are
74 greater than 127. They should only complain if they are greater than
75 511.
76
77 18 phx13416 phx09174
78 GC loses if lisp is invoked in a ring less than 4. There seem to be
79 some places where pointers with ring-number equal to R|4 are created,
80 although they point into ring-1 segments. Referencing through these
81 causes a fault, of course.
82
83 16 phx18177 phx19012
84 Compiling a defpl1 with a return char * varying last parameter
85 causes a complaint about a "funny word" and an illegal modifier fault.
86
87 15 phx17777
88 nthcdr N LIST returns nil if the Nth cdr of LIST is a symbol. It
89 takes an illegal modifier fault at lisp_car_cdrs_|163 if it is a
90 fixnum. This is because it checks for the end of the list before it
91 checks to see whether it has taken N cdr's already.
92
93 14 phx16613
94 cursorpos '\ does what cursorpos ') should do and vice-versa.
95
96 11 phx15718
97 If an alarmclock timer goes off while the lisp invocation is suspended
98 it prints a message but does not do a start control order.
99
100 10 phx15600
101 The "let" fsubr acts like the let* fsubr i.e. it performs its
102 bindings serially instead of in parallel. It is correct in the
103 compiler which just treats let as a macro for a lambda binding. The
104 interpreter should be changed to use the macro definition and let*
105 should be added as the name of this fsubr.
106
107 9 phx09429
108 The lisp interpreter should enable mulquit and mulpi by default. This
109 incompatible change is more than justified by compatibility with the
110 rest of Multics.
111
112 7 phx11203
113 Compiling the following function gets the error:
114 Compiler Error: 1 2 are unequal pass1 and pass2 counts.
115
116 defun make-strange-lcp-err
117 subrcall X
118
119 6 phx10222
120 The garbage collector sometimes attempts to reference through a null
121 pointer.
122
123 5 phx09829
124 Lisp expands pathnames relative to the working dir at the time Lisp was
125 invoked not the wdir in effect at the time of reference.
126
127 4 phx09385
128 The following scenario will cause a compiler error complaining about
129 being unable to find an entrypoint:
130 1) the object segment already exists and is found by a link into a
131 directory in which the user only has s access.
132 2) The program is compiled with -list
133 3) Severe errors are found during compilation.
134
135 make_lisp_listing loses when it tries to find the symbol table of the
136 object segment.
137
138 3 phx08651
139 lcp ignores invalid control arguments instead of aborting.
140
141 2
142 The lisp linker should ignore null file system links when searching for
143 a name. This is in keeping with the standard linker and makes things
144 like deleting a private version of some lisp library much less
145 painfull.
146
147 1 phx12837
148 Lisp should provide a mechanism for establishing handlers for arbitrary
149 conditions. It currently only deals with program_interrupt.