FM>> Sure, but I think the problem is in PKT2QWK.

RS> Without much evidence tho.

PE> I know this may come as a great shock to your belief system,

No news to me boy.

PE> but don't you think there is the possibility that the bug (if any)
PE> is in PKT2QWK, but data-dependent?

Yep, as I said in another, its possible and until we have actually found
the bug which is producing dud QWKs, nothing is absolutely certain.

Corse in this case its well down the list of possibilitys coz no one else
is currently seeing that problem. That makes it far far more likely that
its something in the BAT files or the config of the machine on which the
QWK is produced.

Yes, its certainly possible that say one particular echo which Frank reads
and no one else does has some mail which when included in the combined PKT
is enough to make visible a bug in PKT2QWK, Its conceivable that say one
particular bit of gating software manages to produce messages which have
something unusual about them which PKT2QWK doesnt like. But its well down
the list of likelys.

PE> ie if you pass it a huge packet (pktjoin operating on all your
PE> packets), it screws up, but if you pass it a small packet (process
PE> the packets individually), it doesn't?

That one is even less likely coz it doesnt appear that Frank is getting
a total file size bigger than anyone else. I have had everything from
1M to 20K QWKs produced so I think that particular possibility is rather
remote. But its certainly possible that there is just a narrow range of
sizes of the PKT which makes that bug visible and its just happened to
apply its fangs to Franks arse. Even less likely tho.

PE> When you add to that the fact that pqwk is far more complicated
PE> than pktjoin, written by multiple authors, basically a heap of
PE> shit, had quite a lot of bug fixes go through already, whilst
PE> the pktjoin code is about 3 pages long,

Sure, no argument there. Main problem tho is that everyone else is
using PKT2QWK, have been doing so for the best part of a year now.
Frank is the only one who is seeing the dud QWKs at the moment. So
its less likely that it is PKT2QWK than his BAT files, which he has
changed, or his machine config.

PE> you would have to be on drugs to be saying the pktjoin is more
PE> likely to be problem than pqwk.

But you keep studiously ignoring the situation where processing more
than one archived file of PKTs in a single run produces a fucked QWK
and processing them individually does not. Particularly when the
resulting QWK with the multiple archive files is nothing unusual size
wise. THATs the symptoms which make it more likely its PKTJOIN, no
matter how unlikely that looks from the code of PKTJOIN.

AND I just dont buy this 'look at the code, its so simple' line, it
wouldnt be the first time that some compiler has managed to produce
an EXE from very simple code which has some subtle problem which
causes it to go bang on some particular detail of its input files.

Corse its also quite possible that Franks problem is a different one
entirely and since I havent seen that problem for many months, that
what I currently think is quite likely, that its his BAT files or his
machine config. But its certainly possible that its PKT2QWK.

Corse in the strictest sense you can argue that it is always a PKT2QWK
bug if its too stupid to notice a fucked input PKT and just blindly
produces a fucked QWK from it too.

Just what you call the reliance on no existing NDXs when PKT2QWK starts
is also arguable. If you want to be totally hair splitting even that can
be called a bug sort of.

--- PQWK202