chuqui@nsc.UUCP (06/09/84)
This is the second or third report I've had on this. I DON'T have it at my
site which is a 780 running 4.2 and VT100 compatibles. The only thing I can
think that MIGHT be causing this is one change I made to the termcap
routines because they used the TS field instead of the TI field. Some
termcaps evidently are also set up incorrectly. I don't know if this is
it, but that is all I can think of. If you are having the problem and can
get me stack traces or any information at all on why it happens I'll try to
find a fix for it as soon as I can.
There ARE some pieces missing to the vnews distribution that I will try to
take care of Real Soon Now. Specifically, there are two shell scripts
(follow and reply) and the help file. I've just finished a major rewrite of
the Makefile for 2.10.1 and as soon as I add a couple more minor bells and
whistles (it now knows about lint and sccs and reacts in a relatively
sane manner) I will post the rest of vnews stuff with the new Makefile so
people who didn't have it before can compile it.
Oh, yes, one final note: The version of recmail.c that went with 2.10.1
(and I believe before) has a problem that keeps it from working properly
with vnews. I'll post that turkey as well (this will all go out tomorrow or
Monday if I get it done).
*sigh* I should have KNOWN better than to run inews through lint...
chuq
--
>From the ledge of the seventh cornice: Chuq Von Rospach
{amd70,fortune,hplabs,ihnp4}!nsc!chuqui (408) 733-2600 x242
If you let a smile be your umbrella you will get rain up your nose.joe@fluke.UUCP (Joe Kelsey) (06/15/84)
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:
joe@fluke.UUCP (Joe Kelsey) (06/15/84)
> Here are my estimates for the array sizes:
Huh? Where are those array sizes you ask? Well, fumble finger me!
Here are the virterm.c diffs:
*** ../misc/virtterm.c Wed Jun 6 14:58:41 1984
--- virtterm.c Thu Jun 14 13:58:45 1984
***************
*** 565,573
plodput(c) { *plodstr++ = c; }
_amove(row, col) {
! char direct[20];
! char rel[MAXPLEN + MAXLLEN + 50]; /* longest move is full screen */
! char ho[MAXPLEN + MAXLLEN + 50];
int cost, newcost;
register char *movstr;
--- 565,573 -----
plodput(c) { *plodstr++ = c; }
_amove(row, col) {
! char direct[128];
! char rel[(MAXLLEN*10)+(MAXPLEN*10)]; /* longest move is full screen */
! char ho[(MAXLLEN*10)+(MAXPLEN*10)];
int cost, newcost;
register char *movstr;
***************
*** 614,620
_vmove(orow, nrow) {
! char direct[20];
char *saveplod = plodstr;
if (CV) {
--- 614,620 -----
_vmove(orow, nrow) {
! char direct[128];
char *saveplod = plodstr;
if (CV) {
***************
*** 648,655
_hmove(ocol, ncol, row) {
! char direct[20];
! char ret[MAXLLEN + 50];
char *saveplod = plodstr;
char *movstr;
int cost, newcost;
--- 648,655 -----
_hmove(ocol, ncol, row) {
! char direct[128];
! char ret[MAXLLEN * 10];
char *saveplod = plodstr;
char *movstr;
int cost, newcost;
Hopefully, that should fix everything right up.
/Joe