🚀 go-pugleaf

On Saturday, in article <823946625snz@microvst.demon.co.uk>
     tgold@microvst.demon.co.uk "Anthony R. Gold" wrote:

AG> 
AG> I have found that a very small article posted in alt.satellite.tv.europe 
AG> brings down my whole system around my ears.  The posting is unremarkable 
AG> except that the Path: line is 544 characters long.  Shortening this line 
AG> with a text editor will allow everything to proceed normally here.

Anthony, It's interesting to note that you're posting
with Snews 1.29, and presumably also using that version
of unbatch.

The size of the relevant buffer was increased from 512 bytes
to 1025 in 1.30.

But I think you've raised a very interesting point.  Here's
the source comment with that change:

 * Define the size of general purpose buffers (often used to hold
 * subject, newsgroup lines etc.) The original size of 512 can cause
 * overflow problems with some very long header lines.

'Overflow problems' is rather vague.  Sure, developers
can understand that this means the buffer isn't long
enough for practical postings.  But what happens when a
longer line comes in?  The long line will get split,
not pretty, but nothing much else should go wrong,
since fgets() is being used.

Presumably 'whole system around my ears' implies
something rather more spectacular happens.  Since this
is x-posted in a support group, it's worth mentioning..

[Warning: don asbestos NOW!]   :-)

..how hopping mad some developers get (me, for one) when
users report this kind of vague crap instead of
'I had to press ctrl-alt-del', or 'c/a/d didn't work
and I had to power off/on', or 'a message "Out of
memory" flashed on the screen and then I was at the
command prompt', or 'there was a blinding flash of
light, and when I awoke, the computer and monitor were
nestling either side of my head against my ears'.  OK,
Anthony, I guess it was the last of those, right?

[flame off] :-)

Anyhow, it seems like there's some bug that's still
there in principle, even though its likelihood is
much reduced by doubling the buffer size in 1.30.

Fetching the article, I ran it thru 1.30 and 1.29.
Worked ok for me on both.  Perhaps my 1.29 isn't
exactly as released though.  I used options -j and -v,
nothing unusual with those tho.

Maybe it's the article that Hanno's quoting from that
causes the problem.  :-)

Strange path.  Even has a hex 04 character in it!!

Hang on, no it doesn't, that only appears during the
transformation between batch.txt and getting into the
newsbase.  Ahah!  The problem with a long path is that,
even though fgets() chops it and doesn't overflow
'buf', there's a sprintf() call that tacks your own
host and domain on the front of the path, BUT WRITES
THAT LONGER STRING INTO ANOTHER BUFFER OF THE ONLY THE
SAME SIZE!

It would be more economical, as well as safer, if
buf2 (.5K in 1.29, 1K in 1.30) were not allocated
until it's needed, and then made the exact length
required.

However, I think there's more than one bug here.
Otherwise how can that hex 04 be explained even
in unbatch 1.30?

Answer: it can't.  Turns out I was running unbatch 1.29
as standard, even tho I thought I'd installed 1.30!
Recommendation: a version string somewhere within
unbatch.exe would be appreciated!  (And thanks to
Anthony for alerting me that I'd not updated my
system correctly).

Summary: the above is an unexpurgated account of
my travels, and much of what I've reported isn't
true!  But I still think the code around sprintf
should be amended.

sprintf() is a brain damaged library function.  Any
function that writes into an array should have a
parameter that gives the no. of elements of the
array.  Sadly we have to live with sprintf, since
it's defined in ISO C, but all calls to it should
always be carefully reviewed.

--
John Washington