Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!servalan!rmtodd
From: rmtodd@servalan.uucp (Richard Todd)
Newsgroups: comp.unix.aux
Subject: Re: C compilers for A/UX
Message-ID: <1990Sep11.174416.5711@servalan.uucp>
Date: 11 Sep 90 17:44:16 GMT
References: <3361@dftsrv.gsfc.nasa.gov> <3362@dftsrv.gsfc.nasa.gov> <1990Sep10.002711.22219@servalan.uucp> <3380@dftsrv.gsfc.nasa.gov>
Organization: Ministry of Silly Walks
Lines: 35

jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes:

>>A/UX cc stable???

>By stable, I mean that it produces solid code. Maybe stable was the wrong
>term, but I stand behind my opinion.

Okay, I'll agree with you here.  When A/UX cc does compile a program, it 
does seem to compile it correctly.  

[talking about the infamous -fwritable-strings]

>Maybe that was it... I was compiling with -traditional. This happened with
>my port of ftpd, sendmail and fingerd, which all use sscanf (amongst others)
>so that may be the problems. Seems to me, the default should be -fwri* since,
>as I understand it, this is basically an ANSI "feature", and should be added
>when one selects -ansi...

Perhaps it should.  In fact, it shouldn't be difficult to hack the gcc driver
to do just that.  Of course, it'd be better if Apple also fixed the bug in
sscanf/ungetc that does this; sscanf really has no business trying to write
to its input.  I certainly never had suspected that sscanf did such a thing
until the reports came out on comp.windows.x (among other places) about the
bug.

>Thanks for the help, but maybe my attitude towards gcc may be a little tainted
>by FSF and their "holier than thou" attitude.

And perhaps my attitude towards A/UX cc is tainted by AT&T and their
attitude of "God forbid we should go to the trouble of mallocing what
we can statically allocate.  You want to compile something with more
than 32K of #defines?  Too bad.  See Figure 1." 
--
Richard Todd	rmtodd@uokmax.ecn.uoknor.edu  rmtodd@chinet.chi.il.us
	rmtodd@servalan.uucp