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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,17e99293e94a7e6f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-31 03:44:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn14feed!wn12feed!worldnet.att.net!207.217.77.102!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail From: "Eric G. Miller" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Another ammunition References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 31 Dec 2002 11:43:36 GMT NNTP-Posting-Host: 199.174.209.210 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1041335016 199.174.209.210 (Tue, 31 Dec 2002 03:43:36 PST) NNTP-Posting-Date: Tue, 31 Dec 2002 03:43:36 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:32405 Date: 2002-12-31T11:43:36+00:00 List-Id: 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).