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.