turner@imagen.UUCP (D'arc Angel) (01/09/87)
i just installed the new version of vn and have run into a problem,
it seems that a lot of the postings from BITNET have a \0a in the
From: line of the header. This causes gethead to think it has
finished reading the header and return with lin (number of lines in
the atricle) set to zero. My fix was to check for zero and set lin
to some artbitrary number, anyone have a fix to let me finish
decoding the header lines ??
--
---------------
"I will drink of every cup once" saith Jurgen - James Branch Cambell
Mail: Imagen Corp. 2650 San Tomas Expressway Santa Clara, CA 95052-8101
UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner AT&T: (408) 986-9400bobm@rtech.UUCP (Bob Mcqueer) (01/13/87)
in article <754@imagen.UUCP>, turner@imagen.UUCP (D'arc Angel) says: > i just installed the new version of vn and have run into a problem, > it seems that a lot of the postings from BITNET have a \0a in the > From: line of the header. This causes gethead to think it has > finished reading the header and return with lin (number of lines in > the atricle) set to zero. Our site doesn't seem to have this problem - our BITNET articles don't seem to have an offending \0 embedded in header lines. If this IS a widespread problem (or even if it isn't, I guess), my suggestion: The problem is that fgets() takes \0 for a line terminator. Rather than special casing a lot of stuff, replace the fgets() call with a special routine that looks explicitly for the \n, and throws away \0's as it comes to them. If this is a widespread problem: 1) I'll incorporate a special "fgets" into vn - this fgets could also handle a buffer size more intelligently, so that in the unlikely event that header lines get to be more than RECLEN characters long, it won't goof anything up either. Then, you could tune RECLEN to a more reasonable limit. 2) This really strikes me as a bug in the posting software someplace - article files simply should not contain \0's -- Bob McQueer {amdahl, sun, mtxinu, hoptoad, cpsc6a}!rtech!bobm