vnews bug fixes (virtterm.c)

[Joe Kelsey]

Well, after much weeping and thrashing and knashing of teeth (and a few
more lost hairs) I have finally found the problem with vnews dumping
core.  This problem was especially furstrating because *I* couldn't
make it dump core for me!  No matter what I tried, it just refused to
dump core for me, but I could walk over to any of a select group of
people and they could do it every time!  Add to that the fact that the
error reported was Illegal Instruction, but the stack trace showed
absolutely nothing wrong!  Finally, after three days of no progress, I
thought to check the terminal characteristics of the terminals those
lucky people used, and, viola!  They use 9600 baud and I use 4800!
Now, we use VT100s almost exclusively here, except I have a VT220.  My
termcap for the VT220 has no padding.  VT100 standard termcap has
padding which only really takes effect at 9600 baud and above.  Clues,
clues, kludge!  Look in virtterm.c, function _?move (basically _amove,
but there are others.)  Notice that _amove is trying to find the
shortest possible string to send to the terminal to position the
cursor.  Look up the tputs(3) routine in the manual.  It takes a
function parameter to actually do something with every character
generated.  The simple thing to do here is pass it the address of your
favorite character output routine.  However, you may want to save the
string or something else, so you provide another routine, namely
plodput() (what a name!)  Now look at the nice static array
declarations at the beginning of _amove().  Nice aren't they?  Very
nice, indeed, thank you, until you try to generate a position string
which overflows the bounds of the rel[] array and proceeds to trash the
stack, destroying the return data and causing the ret instruction at
the end of _amove() to cause an illegal instruction trap since the
hardware can't figure out what to do with the garbage that is on the
stack now!

Well, anyway, now that I've bored you all with the horrible discussion
of this problem, how about a solution?  Well, I think the solution is
to fix tputs so that it dynamically allocates the string space for the
output string, but that would cause vi to run even slower on PDP-11s,
and everyone LOVES static arrays that overflow their bounds anyway,
right?  I took the easy way out - increase the declared size of all o f
the arrays used by the _?move routines so we don't overflow anymore (or
at least not until someone tries to run it on something that is slower
than a VT100 and uses and even more baroque escape sequence than ANSI!)

Here are my estimates for the array sizes: