scs@itivax.iti.org (Steve C. Simmons) (06/28/89)
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? Other compilation issues: using gcc I got boatloads of warning messages about functions at first defined as extern then later as static. Doing a quick reshuffle on the code took care of the messages, but I didn't bother with more than a couple of modules. Also, gcc did some heavy barfing when building the initial makefile. As chip rosenthal mentioned in his posting, changing the string * this is probably non-portable so it is ifdef'ed to remove the apostrophe fixes it. Comments -- nn is a nice little package. It has cut down on how long I spend reading news, which sure seem to be the intent. Patch follows. *** orig/nntp.c Sun Jun 25 20:34:45 1989 --- nntp.c Tue Jun 27 09:36:02 1989 *************** *** 32,40 **** #include <netdb.h> /* This is necessary due to the definitions in m-XXX.h */ - #ifdef NETWORK_BYTE_ORDER #include <netinet/in.h> - #endif export char nntp_server[256]; /* name of nntp server */ export int use_nntp = 0; /* bool: t iff we use nntp */ --- 32,38 ----
storm@texas.dk (Kim F. Storm) (06/29/89)
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!