From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 22 Jun 93 06:50:07 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa s.edu!swrinde!network.ucsd.edu!munnari.oz.au!goanna!ok@ucbvax.Berkeley.EDU (Ri chard A. O'Keefe) Subject: Re: Software vendors not using Ada but C Message-ID: <20366@goanna.cs.rmit.oz.au> List-Id: In article <9306180819.aa14968@dsc.blm.gov>, cjames@DSC.BLM.GOV (Colin James 06 21) writes: > Ted Holden writes that "Programs written in geneic C port, from just about > anything to just about anything else". > > This argument is mistaken as anyone knows who has worked on a larger C > project of greater than 10,000 lines of code. Too true. > Consider the generic C statement: c=a+++b; . > > This ambiguous statement can mean four things which are all equally > admissible as ANSI C: This is outrageously false. The ISO standard, section 6, subsection Semantics, paragraph 2, and example 2 make it crystal clear that there is precisely one way of dividing this into tokens: {c} {=} {a} {++} {+} {b} {;} The grammar admits only one parse, and that parse admits only the interpretation > 3. c = a + b ; a = a + 1 ; (If c and a are aliases, the construct is explicitly undefined.) > Note that Appendix F of the the ANSI C standard suggests that in cases > where language syntax is ambiguous, the use of spaces can alleviate > confusion. But who ever heard of an ANSI language which relies on > spaces to que the compiler. That's "cue", not "que". I don't know what appendix F of the ANSI standard might have said, but I can find nothing similar in appendix F of ISO 9899:1990, and in any cases the appendices are informative, not normative. As for spaces having lexical effect, a great many ANSI languages do that, including Ada. Consider x := x -- 1; Here -- begins a comment. x := x - - 1; Here the division into tokens is very different. (The result happens to be illegal _syntax_, but the space has made a lexical difference which is _precisely_ analogous to the C case.) > Also, Mr Holden's argument fails with floating point math for this reason. > Two ANSI C compilers on the same hardware platform can produce different > numerical results because the math stuff in C is done at runtime and it > is not required to be implemented according to any standards. This is > why banks and financial institutions have been burned when herded to C. Be fair. It is entirely possible for two Ada compilers on the same hardware platform to produce different numerical results. (The "two" compilers might well be the same compiler with different optimisation levels.) It is also possible for two Fortran compilers on the same hardware platform to produce different numerical results. It isn't even rare. ISO C provides more information about floating-point types (via ) than Fortran 77 did, which didn't stop Fortran 77 being very useful for numerical work. Banks and financial institutions have been burned using COBOL, Fortran, PL/I, Pascal, RPG, CICS, you name it. Why should C be any different? _Have_ any banks been "herded" to C? Our financial masters are the 500-pound gorillas of the concrete jungle, they go where they want. (I suspect _my_ bank of using an abacus.) > If C is portable as Mr Holden suggests, then why is it that C ports from > one platform to another take so long. In practice, the answer is very simple, and has little to do with the language used: the original code wasn't written to be portable. There is one method that I know of for developing portable code, and that is to develop it on several different machines at the same time. Anyone who wants to develop non-portable Ada code can do it, no trouble. Look, I agree that Ada is a far better language than C. (Which is why I _grabbed_ Ada/Ed for the Mac as soon as I heard about it.) But arguments against C would be so much more convincing if they were _correct_.