Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!kth!sunic!dkuug!tidk!storm
From: storm@texas.dk (Kim F. Storm)
Newsgroups: comp.sources.d
Subject: Re: NN, Network Byte Order, and Sockets
Message-ID: <344@texas.dk>
Date: 28 Jun 89 19:05:50 GMT
References: <1831@itivax.iti.org>
Organization: Texas Instruments, Denmark
Lines: 38

scs@itivax.iti.org (Steve C. Simmons) writes:

>A problem with NN on 4.3BSD vaxen:

>In nntp.c, the inclusion of <netinet/in.h> is controlled by the ifdef
>of NETWORK_BYTE_ORDER.  The m-vax.h file specificly undefines this,
>yet it's clear from the code that nntp.c will never compile without
>netinet/in.h.  Since all our hosts are vaxes network byte order isn't
>really an issue, so I patched as below and it compiled and ran.  Is
>this ifdef as bogus as it looks?

Yes it is broken!  I now realize that it has only been tested on 
configurations where VAXen and SUNs share a NETWORK_DATABASE. In 
this case, the in.h is included in m-vax.h when compiled for the VAX,
and in nntp.c when compiled on the SUN (because it is N_B_O).

However, your patch will break this, because it would cause in.h to
be included twice on the VAX if NETWORK_DATABASE is defined.

A proper fix will be included in the patches which I will post on
comp.sources.bugs later today.

>Other compilation issues: using gcc I got boatloads of warning messages
>about functions at first defined as extern then later as static.
Well, I suppose there is an option to GCC which prevents this.

>Doing a quick reshuffle on the code took care of the messages, but
>I didn't bother with more than a couple of modules.
I advise you not to rearrange source code like this - you may have
problems applying patches to it later on.

>Patch follows.
Use the official patch instead.

-- 
Kim F. Storm        storm@texas.dk        Tel +45 429 174 00
Texas Instruments, Marielundvej 46E, DK-2730 Herlev, Denmark
	  No news is good news, but nn is better!