lwall@sdcrdcf.UUCP (07/12/84)
There is another 1st line bug other than the one usually mentioned. This
one causes the first line of the article to get incorporated as part of the
header. It is triggered by putting spaces or tabs on the supposedly blank
line separated the header and the body of the article. Inews thinks the
blank line is a continuation line, and due to the way it is structured,
ends up ignoring the newline at the end of the blank line, and appending
the newline plus the first line of the article to whichever buffer contains
the last line of the header. (The newline gets included, so when the header
prints out, the 1st line starts its own line but now immediately follows
the header line it got snarfed into.)
Example:
If you post the following:
...
References: <666@man.UUCP>
<space>
[Will someone tell me if there is a 1st line bug?]
Blah, blah, blah.
then you may end up seeing:
...
References <666@man.UUCP>
[Will someone tell me if there is a 1st line bug?]
Lines: 20
Blah, blah, blah.
Subsequent rnewses may insert an extra blank line before the "[Will..." line,
but the damage is already done. I don't know how many inewses out there
have the problem. The problem manifests itself less frequently than the
usual 1st line bug because people don't put spaces on the blank line as often
as they do at the beginning of the 1st line.
The patch we did on our system is to add 2 lines to header.c making blank
lines with whitespace equivalent to a blank line:
while ((c = getc(fp)) == ' ' || c == '\t') { /* for each cont line */
/* Continuation line. */
while ((c = getc(fp)) == ' ' || c == '\t') /* skip white space */
;
+ if (c == '\n') /* oops, it's really a blank line (I hope) */
+ break;
if (tp-cp < len) {*tp++ = ' '; *tp++ = c;}
while ((c = getc(fp)) != '\n' && c != EOF)
if (tp-cp < len) *tp++ = c;
}
Note that the line starting "if (tp-cp < len)" salts away c without ever
checking to see if it's a newline.
Here is an article that came in today with evidence of the bug:
----------------
>Relay-Version: version B 2.10 beta 3/9/83; site sdcrdcf.UUCP
>Posting-Version: version B 2.10.1.chuqui 4/7/84; site nsc.UUCP
>Path: sdcrdcf!hplabs!nsc!chongo
>From: chongo@nsc.UUCP (Landon C. Noll)
>Newsgroups: net.news.group,net.astro
>Subject: Re: STARDATE to be posted
>Message-ID: <1171@nsc.UUCP>
>Date: Wed, 11-Jul-84 11:12:47 PDT
>Article-I.D.: nsc.1171
>Posted: Wed Jul 11 11:12:47 1984
>Date-Received: Wed, 11-Jul-84 20:12:49 PDT
>References: <173@utastro.UUCP>
>Lines: 10
>
>i welcome the chance for STARDATE to be posted. i believe it is a GOOD
>Organization: National Semiconductor, Sunnyvale
>Lines: 6
>
>thing. (*YUMMO*) net.astro is JUST fine for the discussion. there is
>NO need for a sub-group. there is a reason why it should not go in
>net.astro.expert (no slight ment to the STARDATE people), but SOMETHING
>has to go in net.astro!
>
>chongo <> /\../\
------------------
Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
P.S. I noticed this bug ages ago, but I thought someone had fixed it
already, so I didn't say anything. But I noticed my pre-release 2.11 still
has the problem, if I read it correctly.