Re: [leafnode-list] More embedded NULLs in posts

[Mike Castle <dalgoda@xxxxxxxxxxxxx>]

On Sun, Aug 13, 2000 at 06:09:22AM +0200, Matthias Andree wrote:
> Mike Castle <dalgoda@xxxxxxxxxxxxx> writes:
> > Ok, getaline() is still broken.  Less broken, but still broken.
> > 
> > Just because line is zero length, it doesn't mean it's an error or end of
> > file.
> 
> A line cannot be zero length unless you strip the LF.
> 
> If you get a zero length, it means that either fgets has returned NULL
> (EOF/error condition without read) or fgets has returned a 0 byte as the
> first byte read, on which we puke.

There is no need to puke, though.

> I know this sucks, but \0s don't belong in news in the first
> place. leafnode should move the offending file out of the way, or if
> it's getting news via network, discard the offending article noisily.

If fetchnews just discarded the article, that would be fine.  But it
doesn't.  It chokes on the whole group.

> Would you care to elaborate what the rest of leafnode should do if you
> return the empty string instead of the null pointer? Actually, the
> entire software should bail out and give up on that article. I'm not
> sure if the callers of getaline() handle this. I haven't looked. I have
> the imagination it would be a caller problem, not a callee function,
> thus, fixing getaline is operating on the wrong patient.

Well, they should already handle the empty string.  Because, after all,
getaline() strips any CR or LF on the line before returning it, and so, if
the line consists of nothing but a LF, then getaline() returns an emptry
string.  So the callers had better be prepared to handle that as it is!

> I understand that after your patch, you're silently discarding the
> entire line between the NUL byte and the LF and return success. I think,
> returning error condition is better in this case.

Actually, it's not that simple.

Let's say we come across a line that is 19 nuls followed by NL and our
current buffer is 11.
We would return once, for the first 10 bytes, and we process it as a line.
Then we call again, and get the other 9 nulls, the NL, and process it as a
line.  So, we turned one line that was larger than the current buffer into
two lines.

Now, maybe that's a surprise.  But that should never happen except on
broken posts.

Right now, getaline() has only one way of indicating a failure:  returning
NULL.  To fetchnews, this means a read failed before a "." indicating end
of input.

Under what conditions, that didn't require completely restarting the NNTP
connection anyway, would this really happen?  And would any successive
reads merely cause a broken pipe error that would kill the program anyway?

If so, then we could leave getaline() as is, and change the fetching of a
post to do something different upon receiving a NULL, such as ignoring it,
and trying to read again.   If it's a real error, app will die on broken
pipe.  If it's just a matter of nuls in the input, then it will continue
merrily on it's way.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@xxxxxxxxxxxxx  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list