Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!siri.UIO.NO!ik.naggum-erik From: ik.naggum-erik@siri.UIO.NO Newsgroups: comp.os.vms Subject: Re: Why blast poor VAX C? Message-ID: <10493.8707211732@verdande.UIO.NO> Date: Wed, 22-Jul-87 20:48:07 EDT Article-I.D.: verdande.10493.8707211732 Posted: Wed Jul 22 20:48:07 1987 Date-Received: Sat, 25-Jul-87 01:37:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Rahul Mangaldas (rmangald@clarku.bitnet) criticizes my criticism of John Yates' (yates@a.chem.upenn.edu) criticism of C in the case of the C language vs the g-floating point format. It never occured to me that John could be suspected of not being a programmer, but this note may be worthy of bandwidth: In C, a parameter declared asis automagically converted to . Then we have scanf, which is a quite different issue from G-floating formats. Scanf uses pointers to store things, and calamities may arise if you store a value into a slot. Add to this the fact that g-floating s and s do not carry the same relationship as "normal" s and s. (K&R assumes that is just a longer mantissa. John's code (sans the mth$cvt_d_g) works on a Ultrix 2.0 machine, in default floating format.) This was his error in programming. Then the issue of G-floating, and whether this is a fault of the C language, which was part of what I got out of John's article. He assumed that since things worked with Fortran on a VAX, it would work equally well with C. (This assumption is correct.) Being sloppy in C is dangerous, and all his comments pertain to this aspect of C programming, not to the language. This was his error in argument. Together the errors are graver than if he had just cried for help. We all make errors now and then. (Even I :-).) Learning from them is what makes this life so beautiful. You are right in that language/OS fanaticism isn't going to get us anywhere. It would perhaps have been better to ask John to pick up K&R instead of putting it away, than to reverse the flaming on VAX and VMS. I hope this did shed some light. On my reaction, if on nothing else. Erik Naggum ARPA: enag@siri.uio.no or enag%siri@ifi.uio.no Manager SNAIL: POB 1560 Vika, N-0118 OSLO 1, NORWAY Naggum Software PHONE: (intl)+47-2-549-163 (0600-1200 GMT) -------