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 as  is 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)
-------