Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site telesoft.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!harpo!decvax!ittvax!dcdwest!sdcsvax!telesoft!pilotti From: pilotti@telesoft.UUCP (Keith Pilotti @shine) Newsgroups: net.news,net.news.b Subject: Re: Netnews failed Message-ID: <156@telesoft.UUCP> Date: Tue, 9-Jul-85 23:17:35 EDT Article-I.D.: telesoft.156 Posted: Tue Jul 9 23:17:35 1985 Date-Received: Fri, 12-Jul-85 03:28:09 EDT References: <162@epson.UUCP> <225@ncr-tp.UUCP> <> Reply-To: pilotti@telesoft.UUCP (Keith Pilotti @shine) Organization: TeleSoft, SanDiego CA Lines: 79 Xref: watmath net.news:3618 net.news.b:1137 Summary: `rnews' barfs claiming "garbled" news In article <> msb@lsuc.UUCP (Mark Brader|LSUC|Toronto) writes: > >We, too, were getting a number of "inbound batch is garbled" messages >at one time. Accordingly, I replaced the tiny shell script "cunbatch" >... I've experienced a similar message ("inbound news is garbled") from rnews when reading from `uurec'. Let me explain... I am running News B 2.10.2 on Sun Workstations (M68K). There are several "bugs" in this release which I suspect are related to the infamous "VAX --> 68K NULL pointer dereferencing" conflicts present in many C programs written for VAX 4.2BSD. [See end of article for a summary of this pointer problem.] One of the problems I've had to work around is in `uurec'. `uurec' is supposed to receive articles via mail, and submit them directly to `rnews' for posting on the local machine. However, instead of piping to `rnews', it dumps the article on the standard-output. [Note, I do NOT have DEBUG set, and can `grep' "/usr/lib/news/recnews" in the executable `uurec' program.] OK, I says, I can klooj that by explicitly piping, ie (in my aliases file): netnews:"|/usr/lib/news/uurec | /usr/lib/news/rnews ; exit 0" Although the articles received via this mechanism ALWAYS get correctly posted, `rnews' also ALWAYS complains "inbound news is garbled" with the respective returned mail from every machine on my net. This brings us to the "exit 0" which shuts up `sendmail', but clearly might hide some REAL problem. I've only looked at the code cursorily and the problem wasn't immediately obvious. Maybe someone has made the appropriate modifications to the next news release (2.10.3) to account for 68K machines. (I'm afraid they're around to stay awhile...) {:-) Accordingly, if anyone has taken the time to weed these out in the current (2.10.2) release, please send them to me! Thanks... [A quick summary of the "68K NULL pointer problem":] VAX user process space starts at address 0 and therefore dereferencing a NULL pointer merely returns a value of 0, a side-effect which many programs rely on, eg: char *p = NULL ; if ( *p ) puts( "It's not NULL \n" ); else puts( "It sure is \n" ); returns "It sure is " on a VAX. On Suns (and probably other 68K's), this code dereferences into address space which is NEVER owned by the user program. A core dump is the usual result. This kind of code is easily fixed: char *p = NULL ; if ( p && *p ) puts( "It's not NULL \n" ); -->......^^^^ else puts( "It sure is \n" ); There are more subtle variations on this which one might imagine. [END Summary] /+\ Keith ________________________________________________________ KEITH F. PILOTTI -- TeleSoft (619) 457-2700 x172 10639 Roselle St, SanDiego, CA 92121 (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti (ARPA) Pilotti@UCSD