Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84 chuqui version 1.4 9/15/84; site nsc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!cbosgd!ihnp4!nsc!chuqui From: chuqui@nsc.UUCP (Chuqles) Newsgroups: net.sources,net.news.b Subject: minor fixes to inews Message-ID: <1482@nsc.UUCP> Date: Thu, 20-Sep-84 17:54:29 EDT Article-I.D.: nsc.1482 Posted: Thu Sep 20 17:54:29 1984 Date-Received: Tue, 25-Sep-84 07:16:17 EDT Distribution: net Organization: Clown Alley Lines: 56 Here are two minor changes to inews. One is a small efficiency hack, one fixes a problem with a potential buffer overrun and coredumps. Efficiency hack: While inews is processing a message it keeps a variable called chcount of the number of characters in the message. The only use of this variable is to see if the article is too short (too short is arbitrarily set to 5 characters) and if so inews won't post it. With the advent of the new postnews and the 'Replace this line with your message' line and .signature files messages this arbitrarily short become very rare. Besides, I can't see any real justification for 5 characters over 4 or 6. Since this is the only use for that variable I just ripped it and the references out completely. People who REALLY want inews to dump short messages should use the associated line counter variable instead and dump out messages shorter than some number of lines since that variable is counted anyway and used elsewhere at all. ------- inews.c ------- 591d590 < long chcount = 0; 641,642d639 < if (isprint(c)) < chcount++; 679,682d675 < if (chcount < 5 && mode <= UNPROC && !is_ctl) { < fprintf(stderr,"Body of article too short, not posted\n"); < xxit(1); < } This is a more serious problem. As I was bringing up 2.10.2 I found that inews was disappearing into thin air leaving locks and not finishing its job. Tracking it down with dbx (which is how I found the above as well-- when dbx is single stepping unneccessary loops and things become painfully obvious) it turns out that the routine genversion() was overflowing a small buffer. Genversion() creates the version string that is sent out in every message header. In my case I am keeping both the original version number from Rick and my own version number so I have a reference to where it started and what I've done with it. This overflows the measley 32 byte buffer (I actually think that many of the version strings created overflow the 32 byte buffer, but mine is long enough to overflow into something critical). By increasing the buffer size things work again. ------- header.c ------- 435c435 < static char retbuf[32]; --- > static char retbuf[BUFLEN]; -- From the spotlight of the center ring: Chuqles Von Rospach {amd,decwrl,fortune,hplabs,ihnp4}!nsc!chuqui nsc!chuqui@decwrl.ARPA Never force anyone to do anything for you 'in the name of love.' Love is not to be bargained for.