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