[news.software.anu-news] FIX for Bug in V5.9x Processing of some NEWS batches

SMITH%MCCLB0.MED.NYU.EDU@CUNYVM.CUNY.EDU (Ross Smith: (212) 340-5356) (01/09/90)

Hi everybody:
     
I just got the following patch for NEWSADD.C which I installed and tested
this morning.  It successfully ADDed all the news items in the 417 block
newsbatch file which I had abstracted in my posting a few days ago.  So I
guess this is a good fix.  I am currently not able to test it more thoroughly
since we managed to get NNTP to work again, and do not need this kind of mail
news feed (at least until NNTP breaks again).
     
Thanks, John, for the help. I really appreciate it!
     
=============================== John's Reply =============================
     
Date: Sun, 7 Jan 90 21:17 CST
From: NUNN%cl.uh.edu@RELAY.CS.NET
Subject: RE: Bug in V5.9x NEWS processin some NEWS batches
To: SMITH%MCCLB0.MED.NYU.EDU@cunyvm.cuny.edu
     
>I think this is a bug.  Clearly V5.8 and the V5.9x versions behave
>differently, adn the differences essentially make V5.9x unusable with a news
>feed via mail of the type we were getting.
     
        Ross,
     
        I experienced the same problem,  and after checking I
        found that a change made for 5.8 broke my batch adds.
        The patch below fixed the problem.
     
        Let me know if this corrects your problem.
     
        John
     
*** newsadd.c;3
--- newsadd.c;2
**************
*** 1513,1519
          return(0);
          }
        } while (!strcmp(add_inline,"\f\n"));
-       if (!strncmp(add_inline,"From:",5)) first_msg = 0;
      }
     
    else if (n_stripping) {
--- 1513,1518 -----
          return(0);
          }
        } while (!strcmp(add_inline,"\f\n"));
      }
     
    else if (n_stripping) {
     
===============<<< end of message >>>=================

gih900@UUNET.UU.NET (Geoff Huston) (01/17/90)

>I just got the following patch for NEWSADD.C which I installed and tested
>this morning.  It successfully ADDed all the news items in the 417 block
>newsbatch file which I had abstracted in my posting a few days ago.  So I
>guess this is a good fix.  I am currently not able to test it more thoroughly
>since we managed to get NNTP to work again, and do not need this kind of mail
>news feed (at least until NNTP breaks again).
     
I got to admit this one is somewhat curious. I looked at the extracted batch
file, and then looked at the fix as suggested in this posting and found the
following problems:
     
 a) I'm not sure that the "sample" input was precisely the input that
    you are actually processing. I get a bit worried when I see input
    lines of the form:
     
      NPath: <path text>
          <continuation line>
      NFrom: <from text>
     
    As I understand the prefixing of the 'N' happens AFTER all other
    processing, INCLUDING the generation of cont lines, so the actual input
    SHOULD be:
     
      NPath: <path text>
      N   <continuation line>
      NFrom: <from text>
     
    If not then NEWS will barf on this, as when NEWS switches to "N-stripping"
    the FIRST line NOT prefixed with an 'N' will cause the generation of
    an end-of-item marker. This will start to cause strange problems with NEWS,
    as the code is NOT built to recover from the errors this input will cause.
     
     
  b) secondly the fix as reported did not appear to solve the problem (yes
     there was a problem). I am yet to be convinced that the fix is not a noop
     as the exact code is executed 5 lines further down in the code.
     
     As I saw the problem from debug runs, the sequence of:
     
        Nlast line of prev item
        <ff>
        From: vms header of next mail item
     
     incorrectly handles the <ff> line, resulting on the From: header being
     interpreted as the body of a null item.
     
    The fix which DOES address this problem is as follows:
     
     
NEWSADD.C
     
static
get_line()
{
  int get_return;
  char *cp;
     
  if (next_eof) infile_eof = 1;
  if (infile_eof) return(0);
     
  if (first_get_call) {
    first_get_call = 0;
    do {
      if (!fgets(add_inline,512,fpr)) {
        infile_eof = 1;
        return(0);
        }
      } while (!strcmp(add_inline,"\f\n"));
    }
  else if (n_stripping) {
    if (*fline == 'N') strcpy(add_inline,&fline[1]);
    else {
      strcpy(add_inline,fline);	/* new code: reset parser for next message */
      infile_eom = 1;
      }
    }
  else strcpy(add_inline,fline);
  get_return = fgets(fline,512,fpr);
  if (get_return) {
    if ((cp = strchr(fline,'\r')) && !strcmp(cp,"\r\n")) strcpy(cp,"\n");
    if (   first_msg
        && !strcmp(add_inline,"\f\n")
        && !strncmp(fline,"From:",5))
      first_msg = 0;
    else if (   !strncmp(add_inline,"#! rnews ",9)
	     || !strncmp(add_inline,"N#! rnews ",10)
	     || (   !strcmp(add_inline,"\f\n")
                 && (   !strncmp(fline,"From:",5)
                     || !strncmp(fline,"Path:",5)
		     || !strncmp(fline,"NPath:",6)
		     || !strncmp(fline,"Relay-Version:",14)
		     || !strncmp(fline,"NRelay-Version:",15)))) {
      infile_eom = 1;
      }
    while (   infile_eom
	   &&
              (   !strcmp(add_inline,"\f\n")
	       || !strncmp(add_inline,"#! rnews ",9)
               || !strncmp(add_inline,"N#! rnews ",10))) {
      strcpy(add_inline,fline);
      if (!fgets(fline,512,fpr)) {
        infile_eof = 1;
        return(0);
        }
      }
    return(1);
    }
  next_eof = 1;
  strcpy(fline,"");
  return(1);
}
     
     
As well as adding the additional line of code, I have rewritten a number of
lines into a larger single expression - as this code is called pretty
constantly the elimination of repeated checks for the same condition can only
improve runtimes.
     
     
Geoff Huston