Re: An interesting object lesson (Ada vs C)

[Jonathan Guthrie <jguthrie@brokersys.com>]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> 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.