🚀 go-pugleaf

In article <828509580snz@pdlmail.demon.co.uk>
   Peter Disdale <Pete@pdlmail.demon.co.uk> writes:
> 
> Of interest is the appending of Malcolm's reply to a different
> thread; this article does not appear in my list (wrong count?).

It suggests that the count was higher than Snews' unbatch thought it 
should be (and it thus took unbatch on into the next article). I'm not 
sure exactly how unbatch interprets the character count.

It also fooled Cppnews' unbatch (obviously, since that's how I started 
the thread). Given that both were fooled, I'd be inclined to say the bug 
was in KA9Q rather than unbatch.

<LATER>

I've just counted the characters in the article, and KA9Q appears to have 
been twelve short. 

(Method used: save article from batch.txt to file, without the !# rnews 
lines. Size of file: 17832 bytes. Number of lines in file: 55, so 55 of 
the chars in that 17832 are <CR>'s which shouldn't be counted (<CR><LF> = 
1 char). Total byte count is therefore 17777 bytes. KA9Q reported 17765 
bytes, 12 bytes short.)

<LATER LATER>

Interestingly, when my post including a copy of the article arrived, 
cppnews unbatch also got confused (as did your Snews unbatch - sorry for 
transporting the problem here for a few others to get caught out). I just 
checked the article counts for my article - again, KA9Q was 12 bytes 
short. Odd... 

<LATER LATER LATER>

One final check of the offending article shows that there are exactly 
twelve lines containing 1025 space chars (along with several other 
shorter lines). KA9Q has a 1024 char/line limit to its count, does it? 
Looks like it to me. It still seems to receive the extra characters (or, 
maybe, the extra characters are spurious ones added falsely by KA9Q - 
maybe someone with access to the original article can check this?)

Mark.
-- 
int MeaningOfLife (void) { return 42; }   // mcr@holly.demon.co.uk
function MeaningOfLife :integer; begin MeaningOfLife := 6 * 9 end;