Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 Fluke 1/4/84; site fluke.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!ssc-vax!fluke!joe From: joe@fluke.UUCP (Joe Kelsey) Newsgroups: net.sources,net.news.b Subject: Re: vnews bug fixes (virtterm.c) Message-ID: <1665@vax4.fluke.UUCP> Date: Thu, 14-Jun-84 18:19:19 EDT Article-I.D.: vax4.1665 Posted: Thu Jun 14 18:19:19 1984 Date-Received: Sat, 16-Jun-84 03:50:51 EDT References: <1012@nsc.UUCP> <127@muddcs.UUCP> <1040@nsc.UUCP> Organization: John Fluke Mfg. Co., Everett, WA Lines: 41 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: