paul@devon.LNS.PA.US (Paul Sutcliffe Jr.) (11/17/89)
[ RN 4.3, patchlevel 40: ] When I first ported RN (several years ago) to my system, I would occasionally get the message % interp buffer overflow! when attempting to (F)ollowup to an article. I asked the net for a fix, and one was given. However, I no longer remember what the fix was, and (you guessed it) now that I've recompiled RN, I'm getting the error again. Will anyone who remembers the fix for this please send me e-mail? Thanks in advance. - paul -- INTERNET: paul@devon.lns.pa.us | (All together now:) UUCP: ...!rutgers!devon!paul | Life is just a cherr of bowlies!
csu@alembic.acs.com (Dave Mack) (11/19/89)
In article <3678@devon.LNS.PA.US> paul@devon.LNS.PA.US (Paul Sutcliffe Jr.) writes: >[ RN 4.3, patchlevel 40: ] > >When I first ported RN (several years ago) to my system, I would >occasionally get the message > > % interp buffer overflow! > >when attempting to (F)ollowup to an article. I asked the net for >a fix, and one was given. However, I no longer remember what the >fix was, and (you guessed it) now that I've recompiled RN, I'm >getting the error again. > >Will anyone who remembers the fix for this please send me e-mail? Arrrrrgh. Apply this patch. It works. Given C News message IDs, everyone will need it very soon. It provides a 2k buffer for the references line. This should prevent this problem for the next couple of months. Courtesy of Joe Buck: Index: respond.c Prereq: 4.3.1.5 *** OLDrespond.c Wed Sep 18 01:11:37 1985 --- respond.c Tue May 2 13:50:39 1989 *************** *** 1,6 **** ! /* $Header: respond.c,v 4.3.1.5 85/09/10 11:05:00 lwall Exp $ * * $Log: respond.c,v $ * Revision 4.3.1.5 85/09/10 11:05:00 lwall * Improved %m in in_char(). * --- 1,10 ---- ! /* $Header: respond.c,v 4.3.1.5+JTB 89/04/02 13:44:00 jbuck Exp $ * * $Log: respond.c,v $ + * + * Revision 4.3.1.5+JTB 89/05/02 13:44:00 jbuck + * Made a separate, quadruple-size buffer for header in followup. + * * Revision 4.3.1.5 85/09/10 11:05:00 lwall * Improved %m in in_char(). * *************** *** 354,359 **** --- 358,364 ---- followup() { bool incl_body = (*buf == 'F'); + char hbuf[4*LBUFLEN]; /* four times the old size */ artopen(art); tmpfp = fopen(headname,"w"); *************** *** 361,368 **** printf(cantcreate,headname) FLUSH; return; } ! interp(buf, (sizeof buf), getval("NEWSHEADER",NEWSHEADER)); ! fprintf(tmpfp,"%s",buf); if (incl_body && artfp != Nullfp) { #ifdef VERBOSE if (verbose) --- 366,373 ---- printf(cantcreate,headname) FLUSH; return; } ! interp(hbuf, (sizeof hbuf), getval("NEWSHEADER",NEWSHEADER)); ! fprintf(tmpfp,"%s",hbuf); if (incl_body && artfp != Nullfp) { #ifdef VERBOSE if (verbose) -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
brad@looking.on.ca (Brad Templeton) (11/20/89)
In article <1989Nov19.065842.2745@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: >Apply this patch. It works. Given C News message IDs, everyone will need it >very soon. It provides a 2k buffer for the references line. This should >prevent this problem for the next couple of months. Yeah, I gotta admit I am a bit surprised at this choice in C news. I thought the whole idea was that inews was allowed to be slow and do things like get a sequence number. Putting in the date (which is already on the date line) seems a bit wasteful. And if it adds 16 bytes to each message-id, plus 16 to each followup, and there are mabye 8000 message-ids referenced or produce on USENET each day, and the phone company bills about $10/K for USENET traffic. (And UUNET perhaps about $0.30 for each K posted to USENET) So this longer message-ID bills $1,280 extra per day for the phone company, and $13,000/year for UUNET. So I wonder how much AT&T paid Geoff & Henry? And perhaps Rick is a bigger fan of C news then he lets on, eh? In case you haven't figured it out, :-), :-) (Although the numbers are close to real, although it's just a guess on UUNET, and it assumes everybody ran C news.) After all, just think what the telcos must be paying me to push for full References chains! -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
henry@utzoo.uucp (Henry Spencer) (11/21/89)
In article <50118@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Yeah, I gotta admit I am a bit surprised at this choice in C news. I >thought the whole idea was that inews was allowed to be slow and do things >like get a sequence number. Putting in the date (which is already on >the date line) seems a bit wasteful. It's not a question of wanting the date in the message-id; it's a question of wanting a decentralized message-id-generation algorithm that doesn't need exclusive (i.e. with a locking protocol) access to a central file. Generating based on time and process-id is the obvious approach. I concede that the result is rather long message-ids -- there is a mod to shorten them in our low-priority to-be-examined queue -- but we aren't the only ones using this approach. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
flee@shire.cs.psu.edu (Felix Lee) (11/21/89)
Dave Mack <csu@alembic.acs.com> wrote: >> % interp buffer overflow! > Apply this patch. The quicker hack is to increase LBUFLEN (and probably CBUFLEN) in common.h; fend off all sorts of different buffer overflows. 4096 is a goodly number, assuming you're not hurting for memory or swap space. A proper fix would take a minor rewrite. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/21/89)
>The quicker hack is to increase LBUFLEN (and probably CBUFLEN) in >common.h; fend off all sorts of different buffer overflows. 4096 is a >goodly number, assuming you're not hurting for memory or swap space. Another quick but efficient way is to increase just the size of buf[] and cmd_buf[] in common.h. -- Jon Zeeff <zeeff@b-tech.ann-arbor.mi.us> Branch Technology <zeeff@b-tech.mi.org> It's 1989. Does your software support the ISO 8859 character sets?
bill@flash.UUCP (William Swan) (11/22/89)
In article <21Nov89.35A66D7E@b-tech.mi.org> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: }>The quicker hack is to increase LBUFLEN (and probably CBUFLEN) in }>common.h; fend off all sorts of different buffer overflows. 4096 is [...] }Another quick but efficient way is to increase just the size of }buf[] and cmd_buf[] in common.h. Both these "fixes" just rely on somebody else shortening the References: line before your site bombs out. -- Bill Swan entropy.ms.washington.edu!sigma!bill Send postal address for info: Innocent but in prison in Washington State for 13.5 years: Ms. Debbie Runyan: incarcerated 01/1989, scheduled release 07/2002. In now: 0 years, 10 months, 0 weeks, 1 day.
brad@looking.on.ca (Brad Templeton) (11/23/89)
Actually, now that I think about it, increasing CBUFLEN or the intrp buffer for NEWSHEADER in rn doesn't do you enough good. It stops the overflows, the but refs line will still be truncated at 512 bytes. In intrp.c, there is the hard-coded char scrbuf[512]; which should be expanded to CBUFLEN (if it is expanded) or whatever length you are using. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473