Re: Another ammunition

["Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net>]

Jean-Pierre Rosen wrote:
> I know I'm preaching to the choir, but here is another story Ada fans can
> tell to the other guys who say that "language doesn't matter"...
> 
> My son was recently doing an assignment in C, which involved lots of floating
> point computations, and he kept getting inconsistent results. After lots of
> searching, he discovered that NaNs were generated in various places. There
> seemed to be no consistency in the appearing of NaNs: changing optimization
> options, adding intermediate variables in computations, etc. all changed the
> way NaNs were produced.
> 
> Here is what happened: A C function was returning a float, but in some place
> was declared as returning an int. In gcc, a function that returns a float
> leaves the result on the coprocessor stack, NOT on the regular stack.
> Therefore, the return value of the function was not popped off the
> coprocessor stack. And when the coprocessor's stack is full, every floating
> point operation results in NaN....
> 
> It took a week to understand what was happenning. Would not have passed the
> first compilation in Ada. FWIW...

You're right, but I'm sure gcc could have immediately diagnosed the
problem had you turned up the warnings ("conflicting types for...", "previous
declaration of ...").

The fault here is that the C language requires compilers to be very forgiving,
so you have to take explicit actions with compilers to turn warnings into
errors (-Wall -W -O -Werror, for starters).  IME, gcc rarely gives
warnings that are spurious with -Wall (i.e. ignore at your peril).