Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rochester.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rochester!bukys
From: bukys@rochester.UUCP (Liudvikas Bukys)
Newsgroups: net.news.b
Subject: Re: article-eater irony
Message-ID: <11748@rochester.UUCP>
Date: Fri, 20-Sep-85 11:28:56 EDT
Article-I.D.: rocheste.11748
Posted: Fri Sep 20 11:28:56 1985
Date-Received: Sun, 22-Sep-85 06:11:43 EDT
References: <11854@Glacier.ARPA> <928@munnari.OZ>
Organization: U. of Rochester, CS Dept.
Lines: 25

In case anyone's still thinking about finding this bug: some suggestions.

I was one of the first to claim that it wasn't really a problem.  This
was BECAUSE a "problem" which is not really a problem was described as
the source of the black hole.  Namely, it was claimed that it was bad
for news batches to contain "#! rnews" not at the beginning of the
line.  This is not really a problem, as I demonstrated to myself by
making some articles without newlines at the end, batching and
unbatching them.

Furthermore, the 2.10.2 unbatcher is SO simple, it is hard to imagine
how it is going wrong.  It therefore seems likely to me that the input
to the unbatcher is getting munged.

It is very suspicious that this is triggered by articles containing a
0xFF byte.
-	make sure that compress on your machine can handle 0xFF bytes.
-	make sure that your stdio library doesn't sign-extend that 
	character when you getchar() or getc() it.
-	make sure your news paths can transmit everything you send
	over them, all eight bits if necessary.

Finally, don't claim to have "found the problem" unless you accompany
that report with sample articles, and instructions for duplicating the
problem, right down to putting it into rnews and having it disappear.