[comp.sys.next] C Compiler BUG

hoodr@csusac.uucp (Robert Hood) (07/13/89)

	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




-- 
------------------------------------------------------------------------
  Robert Hood   -- California State University:  Sacramento (ooooh...)
    UUCP:  ..csusac!hoodr
    BITNet:  NCTP003@CCS.CSUSCC.CALSTATE.EDU

jgreely@giza.cis.ohio-state.edu (J Greely) (07/13/89)

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)

mic@ut-emx.UUCP (Mic Kaczmarczik) (07/14/89)

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

-- 
Mic Kaczmarczik			If you drink, don't drill.
UT Austin Computation Center			-- Matt Groening
mic@emx.utexas.edu	
MIC@UTAIVC.BITNET