Number: 1496

Date: 25-Jun-84 15':50':21

Submitter: Sannella.PA

Source: HThompson.pa

Subject: Fix all system code that use CAR/CDR of non-list': want to run w/ CAR/CDRERR on

Assigned To: 

Attn: jonl, Masinter

Status: Open

In/By: 

Problem Type: Design - Impl

Impact: Serious

Difficulty: Hard

Frequency: Everytime

Priority: Hopefully

System: Language Support

Subsystem: Storage Formats/Mgt

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["JonL.pa" "23-Sep-84 22':59':54" Description':]

Description: '
Date': 22 Jun 84 22':47 PDT'
From': HThompson.pa'
Subject': Lisp': CAR/CDRERR'
To': LispSupport.pa, LispCore↑.pa'
Lisp-System-Date': 21-Jun-84'
Machine-Type': Dorado'
'
In an attempt to mitigate the stack overflow problems my students were experiencing (see recent A.R.s from Lichtenberg) I tried running with CAR/CDRERR turned on - in my opinion the only reasonable way to live.  In 10 minutes I collected the following set of failures in system code':'
'
1) CLISPFOR0 - (CAAR I.S.) where I.S. = (BODY), while dwimifying (bind c while (NUMBERP c← (TEDIT.FIND ts "'
")) do (TEDIT.DELETE ts c 2))'
'
2) PROPERTIES.FROM.FRAMESPEC - ARG NOT LIST   U'
while middle buttoning in a backtrace window'
'
3) \DSPRETTY/SUBPRINT - ARG NOT LIST  T'
'
4)  UNBREAK) - ARG NOT LIST  NOBIND'
'
5) LA.RESET.TEDIT.SYNTAX  - ARG NOT LIST  T'
on way in to send this message.'
'
This seems to me to be a genuinely serious issue - the impact on naive users of stack overflows following from relatively minor programming bugs, when the consequence thereof is all too often to lose the system altogether, is bound to be large and negative.   I realise that the number of places where bad coding style has left problems similar to those described above is likely to be large, but shouldn''t an effort be made to put our own house in order?  For the next little while, an increasingly large proportion of our users will be first-time users, and relatively unsophisticated.  If we turn them off early, we will never get them back.'
'
(signed)'
In the trenches'
'
-----'
'
Date': 24 Jun 84 17':42 PDT'
From': JonL.pa'
Subject': Re': Lisp': CAR/CDRERR'
In-reply-to': HThompson.pa''s message of 22 Jun 84 22':47 PDT'
To': HThompson.pa, Sheil.pa'
cc': LispSupport.pa, LispCore↑.pa'
'
Larry and I have been poking into this one, albeit haphazardly, for some time now.  Your findings are appreciated, and some of them are even "new".  I think the one in CLISPFOR0, and ceratinly the one in SUBPRINT, is related to the random CLISPWORD property of T on certain atoms;  Beau has promised to look into that particular misfeature.'
'
-- JonL --'
'
-----'
'
From': masinter.pa'
Date': 25-Jun-84  1':06':02 PDT'
Subject': Re': Lisp': CAR/CDRERR'
In-reply-to': HThompson''s message of 22 Jun 84 22':47 PDT'
To': HThompson'
cc': LispSupport, LispCore↑'
'
It used to be that you couldn''t run 30 seconds with CAR/CDRERR set on.'
'
After some experimentation I''ve determined that (a) most of the baddies are illegal CARs and not CDRs, while most of the recursive errors from students come from CDRs of non-lists, and (b) few of the system errors are more than one level deep.'
'
I added a feature that CDR/CDRERR = ONCE (or anything not NIL or T) would return a string if given a non-string to CAR or CDR, but error if given a string. That allowed for a one-shot error.'
'
I think I will refine it so that CAR is OK, but CDR errors immediately. If we can run most of the system that way, I''ll make it the default.'
'
'
'
Date': 11 Apr 84 20':34 PST'
From': JonL.pa'
Subject': Lisp': Erroneous CLISPWORD properties on OR, AND and !'
To': LispSupport.pa'
cc': JonL.pa'
'
Lisp System Date': 11-Apr-84 00':53':49'
Machine': Dorado (Ahwahnee)'
Microcode version': 24,4'
Memory size': 10000'
Frequency': Always'
Impact': Fatal in CAR/CDRERR mode, Minor otherwise'
'
'
SUBPRINT (in files PRETTY and NEWPRINTDEF) is taking CAR of the result of (GETP x ''CLISPWORD), which will "die" for x in {OR, AND, !, or, and, !!} because these atoms have T as the property. [actual call in SUBPRINT is to SUPERPRINTGETPROP].'
'
Can anyone explain why these atoms have T as their CLISPWORD?  The manual, page 16.22, documents the CLISPWORD property as being of the form (<keyword> . <name>)'
'
'
'


Workaround: 

Test Case: 

Edit-By: JonL.pa

Edit-Date: 23-Sep-84 22':59':55