TOPS-10 RENAMEF bug found.

[Scott.Fahlman at CMU-10A]

JONL,
More good news.  I have discovered the source of the RENAMEF bug
in TOPS-10 MACLISP.  Once again, I would like you to look over the
suggested fix and install it in the master file if it seems OK to
you.

RENAMEF can take either file arrays or strings or lists.  If we pass
it a list pointing to a closed file, we end up at RENAM2 which
opens the file, renames it, and then (the instruction before RENAM4)
does a JRST RENAM1.  At RENAM1, the first argument is treated as a
file array, and updated entries are stuffed into the appropriate
slots.  If the first arg was a list, this code is still executed
and smashes 6 words of random list space, with totally unpredictable
consequences.  The code at RENAM1 is all fairly new, by the way.
It does not appear in the source we have (I forget the version
number of that).

What we want is to jump to RENAM1 if we have an array first argument
and to RENM1A otherwise.  I believe there is a marker left in AR1
from which this can be determined.  (Set up near the entry to
RENAM2.)  A quick and dirty patch is just to change RENM2A+22 to
JRST RENM1A.  This skips the array updating even where it would be
appropriate, but avoids the random clobberation.

I suspect that this problem has been responsible for a number of phantom
bugs.  In particular, after making the above patch I was unable to
invoke the DELETEF bug mentioned in an earlier note, so maybe it was
the RENAMEF bug all along.  Once the fix is installed, we will see
whether the system works noticeably better.

Regards,
Scott