From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b8effe21a2a8e1cb X-Google-Attributes: gid103376,public From: Jonathan Guthrie Subject: Re: An interesting object lesson (Ada vs C) Date: 1998/04/26 Message-ID: <6hvpf2$77d$1@news.hal-pc.org>#1/1 X-Deja-AN: 347852635 References: Organization: Information Broker Systems Internet Services Newsgroups: comp.lang.ada Date: 1998-04-26T00:00:00+00:00 List-Id: In comp.lang.ada Robert Dewar wrote: > Recently during one of my classes (on microprocessor architecture, where > I asked them to do tests on some particular aspect of MP performance), I > received the message below from a student who really knows what he is > doing, and got completely stumped, to the point, where, as you will see > from the message, he was sure he had found a gcc or Pentium bug. In the C world, "really knows what he is doing" means "knows how to turn the warnings on". Do the student a favor and introduce him to lint and -Wall. Elapsed time to my solution of the problem: 45 seconds. Eliminate the warnings, and the code gives (on my computer) arctan 0.5 = 0.463648 Clock ticks: 1933 > arctan 0 = 3.25435e-229 > Clock ticks: 2160 Wow! I've got a faster computer! (I didn't know that was possible! Maybe it isn't possible. What value of CLOCKS_PER_SEC does he have? Mine is 100.) > How did x get set to 0!?!?!?!? It didn't. It got DISPLAYED as 0. That's what happens when you use compiler-specific extensions (as "long double" is, at least for the time being) without understanding the underlying mechanisms. By the mechanism that printf uses to accept parameters, it had every reason to expect that you would pass it a double, but you passed it a long double. Is this a problem with the language? Well, yes. The original language specified that floating-point values be passed as doubles to avoid this exact problem. Since the prototype system doesn't work with functions with a variable number of procedures, it still uses that mechanism to avoid problems. When ISO C added new (higher-precision) floating-point types without care, they broke that safety net. Of course, using a language that does better type checking would have eliminated the possibility of this particular error. However, this sort of error is common enough to be checked by the compiler, if you tell it to. It is commonly accepted practice (at least with GCC, which doesn't "cry wolf" too often) to enable all the warnings and to not accept the code for test if the compiler emits any warnings during the compile. Frankly, I don't find this sort of error to be very difficult to debug. The errors that drive me up a wall all seem to be language-independant. For example, the last time a problem had me muttering to myself and thinking of compiler (actually, library) bugs, the problem turned out to be a reversed branch. Build me a language that can tell me when I've put "greater than" when I really mean "less than" and you'll have something. (If you could also arrange it to make sure I haven't put "+" when I meant "-" or vice-versa, that would be nice, too.) -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area.