Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!allegra!mp
From: mp@allegra.UUCP
Newsgroups: news.software.b,news.admin,news.misc
Subject: Re: Missing lines from articles
Message-ID: <6710@allegra.UUCP>
Date: Sat, 6-Jun-87 17:02:14 EDT
Article-I.D.: allegra.6710
Posted: Sat Jun  6 17:02:14 1987
Date-Received: Sun, 7-Jun-87 08:44:41 EDT
References: <255@catsim.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 49
Keywords: linecount
Xref: utgpu news.software.b:627 news.admin:442 news.misc:457

One way for extra lines to get into an article is for it to pass
through a system on which rnews finds an illegal header line.  header.c
contains code that attempts to move an illegal header line, and all
subsequent text, down into the body of the message.  It almost always
succeeds.

Under 2.10.1 and possibly other 2.10 versions, a header line that does
not contain a colon followed immediately by a space is considered
illegal.  Most linecount discrepancies I've seen have been off-by-one
because of a header that ends in a line such as "Keywords:".  If additional
header lines follow an illegal header line, they'll be moved down into
the body, too.  For instance, in article <2634@sequent.UUCP>, you may get
5 lines moved down into the body, resulting in the message
"linecount expected 22, got 27".
|From: dahutch@sequent.UUCP (Dwight A. Hutchinson)
|Newsgroups: talk.bizarre
|Subject: Re: Jolt
|Message-ID: <2634@sequent.UUCP>
|References: <6315@dartvax.UUCP> <985@bucsb.bu.edu.UUCP> <6343@dartvax.UUCP>
|Reply-To: dahutch@sequent.UUCP ()
|Followup-To: where ever your fingers go
|Organization: Sequent Computer Systems, Beaverton, OR
|Lines: 22
|Summary:well, gee....
|Expires:nah
|Sender:me, I think...
|Distribution:na
|Keywords:Jersey

Now, some unfortunate behavior sets in when rnews is reading from a
pipe and encounters an illegal header line.

After frmread() reads in all the (legal) header, it may attempt to do
what could be called an unhfgets().  It has saved the file pointer via
ftell() before reading in each header line.  It may do an fseek() to
jump backwards a bit if it thinks there's useful stuff - an illegal
header line - to be saved for inclusion in the body of the article.

Well, under 4.[23]bsd, ftell() on a pipe returns -1.  fseek(fp, -1, 0)
will jump to the end of the input buffer on 4.2bsd, skipping over 1000
or so characters and resulting in a ``line-eaten'' article.  With 2.11, if
the whole article is munched down to 0 lines it'll just be rejected.
Under 4.3bsd it appears the fseek(fp, -1, 0) will not cause any
repositioning at all, and the article will probably wind up missing
just that one illegal header line.
Has anyone fixed this?

	Mark Plotnick
	allegra!mp