This is C-Compiler-BUG in view mode; [Up]
Date: Sun 13-Jul-1989 02:36:13 From: Unknown Subject: C Compiler BUG I ran into some strange compiler behavior on the NeXT. It seems that the C compiler can't handle #ifdef's or #defines inside of a command very well. The following piece code was taken from NetHack 2.3e: #define index strchr (defined in header file) otmp>dknown = index( #ifdef KAA #ifdef SPELLS "/=!?*+)", #else "/=!?*)", #endif #else #ifdef SPELLS "/=!?*+", #else "/=!?*", #endif #endif let) ? 0 : 1; the compiler gives three errors for this code: unterminated #if conditional #else not within a conditional too many (5) args to macro 'index' Notice the lhe last error. ALL of the possiblilities were processed! (too bad we don't have "cpp" so we can see what the preprocessor is doing!) Another piece of code from a different part of nethack also produced a compiler error (notice the #ifdef inside of a command): (void) sprintf(buf, "killed by%s", !strncmp(killer, "the ", 4) ? "" : !strcmp(killer, "starvation") ? "" : !strncmp(killer, "Mr.") ? "" : !strncmp(killer, "Ms.") ? "" : #ifdef STOOGES !strcmp(killer, "Larry") ? "" : !strcmp(killer, "Curly") ? "" : !strcmp(killer, "Moe") ? "" : #endif index(vowels, *killer) ? " an" : " a"); I've also had lots of trouble compiling normal BSD 4.3 source. Many times source that will compile on a "standard" BSD 4.3 will produce lots of compiler "type mismatch" errors.. One more thing: Why isn't there a "/usr/etc/libresolv.a". The NeXT supports networking and nameserving very well, but I would like to compile other networking/nameserver programs too. Robert Hood California State University: Sacramento UUCP: ..ucdavis!csusac!cssexb!hoodr BITNET: nctp003@CCS.CSUSCC.CALSTATE.EDU
Date: Sun 13-Jul-1989 05:56:22 From: Unknown Subject: Re: C Compiler BUG In article <1989Jul12.193615.27988@csusac.uucp> hoodr@csusac.uucp (Robert Hood) writes: >The following piece code was taken from NetHack 2.3e: Unfortunately, this isn't specific enough. Running just this bit through cpp (yes, it's there, right where it's supposed to be) produces (unnecessary whitespace deleted): otmp>dknown = strchr ("/=!?*",let) ? 0 : 1; >#define index strchr (defined in header file) Which header file? /usr/include/string.h has this in it: extern char *index(const char *s, int c); #define index(s,c) strchr(s,c) If NetHack #defines it differently, that might cause your problem. >Another piece of code from a different part of nethack also produced a >compiler error (notice the #ifdef inside of a command): > > !strncmp(killer, "Mr.") ? "" : > !strncmp(killer, "Ms.") ? "" : ^ Both of these lines are garbage (calling strncmp with two arguments), and should rightfully cause an error. #ifdef not important. >I've also had lots of trouble compiling normal BSD 4.3 source. >Many times source that will compile on a "standard" BSD 4.3 will produce >lots of compiler "type mismatch" errors.. Official response from NeXT is to use the -bsd switch to cc (Note that the similar -traditional switch is not supported). The -bsd switch is claimed to ensure "strict BSD semantics", but that's not quite true. The way I've been getting old and ugly software to compile is by hacking standard include files as needed so I can use -traditional. Something else that's frequently necessary for porting non-ANSI code is the -fwritable-strings option (I don't know if this is implied by -bsd. If it isn't, it should be). -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) >From: jans@tekgvs.LABS.TEK.COM (Jan Steinman)
Date: Sun 14-Jul-1989 04:02:35 From: Unknown Subject: Re: C Compiler BUG (really why no libresolv.a) In article <1989Jul12.193615.27988@csusac.uucp> hoodr@csusac.uucp (Robert Hood) writes: > One more thing: Why isn't there a "/usr/etc/libresolv.a". The >NeXT supports networking and nameserving very well, but I would like to >compile other networking/nameserver programs too. You get the resolver versions of routines (gethostbyname(), etc.) for free in the shared C library, so there's no need for a separate resolver library. Just remove the reference to -lresolv and the programs should link and run fine. Mic Kaczmarczik UT Austin Computation Center
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.