From 781416001256364372 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10f5bc,6f6e97a6fdbbf44c X-Google-Attributes: gid10f5bc,public X-Google-Thread: 109fba,6f6e97a6fdbbf44c X-Google-Attributes: gid109fba,public X-Google-Thread: 110292,6f6e97a6fdbbf44c X-Google-Attributes: gid110292,public X-Google-Thread: 1014db,6f6e97a6fdbbf44c X-Google-Attributes: gid1014db,public X-Google-Thread: 1149ec,6f6e97a6fdbbf44c X-Google-Attributes: gid1149ec,public X-Google-Thread: f78e5,6f6e97a6fdbbf44c X-Google-Attributes: gidf78e5,public X-Google-Thread: 102b75,6f6e97a6fdbbf44c X-Google-Attributes: gid102b75,public From: keith@ksmith.com (Keith Smith) Subject: Re: And you thought that the Pentium bug was bad! (Get a load of this!) Date: 1995/07/14 Message-ID: <805780694.19675@ksmith.com> X-Deja-AN: 106176747 chars: 4303 references: <3s2las$1br@hustle.rahul.net> <3tud69$cg7@onramp.arc.nasa.gov> organization: Keith's Public Access Computer System newsgroups: comp.std.c,comp.std.c++,comp.lang.c,comp.lang.c++,comp.sys.intel,comp.arch,comp.software.testing In article <3tud69$cg7@onramp.arc.nasa.gov>, Hugh LaMaster wrote: >A few weeks ago, Ron Guilmette posted an "amusing" example >of a bug in a common compiler, wondering what the reaction >would be. He anticipated, of course, that the reaction >would be restrained, rather than outrage. Of course, he >was right. After all, it was "only" a compiler bug, and >one which was "only" a problem involving the scope of variables. The compiler bug is indeed serious IMHO. There were enough problems with 2.6 compilers that I have _never_ used them for any production work. I had lot's of problems with the 2.6 series every time I used it. >Which all tends to confirm my pre-existing prejudice: >Many people don't know whether or not their answers >are actually correct, and, often enough, don't care >either, as long as any problem is "merely" a software >bug. I disagree. Most of the hacker type people I talk to told me to use gcc-2.5.8 rather than _any_ gcc 2.6.X compiler. I was informed that 2.6.X introduced problems and bugs into lots of code that required careful coding to fix, i.e. the problems were noted immediately and well publicized but there were problems finding them in the compiler. In the case of 486 type code there was no real performance hit using the older compiler so there was no UNSOLVABLE problem, simply use the compiler. A bad chip is a TAD different. Case 1 is that you paid money for it, case 2 being not too many non-techno-wizard type people like to rip open their computers and rip out $500 cpu chips and replace them. In both cases we have _determined_ an incorrect answer. It's just the software answer is easier to correct. >Back when the Intel Pentium bug furor hit, I posed the >question in several of these same groups regarding how >people knew they were getting correct answers. The >reactions were not comforting then, as, indeed, the >reactions to this bug are not comforting, either. >Once again, I am impressed by how easily people brush >off the question of how they know the output from >their programs is correct. This is really the crux of the issue. Often times you don't. Whenever I write a financial report for example I always strain the data thru cross-checks in the code, and generally run an abort if the cross-checks don't jive. Very useful to maintain data integrity and catch stupid logic errors. The difference is that with a _compiler_ bug some relatively simple code additions can help you find and _ELIMINATE_ an incorrect result rather quickly, by re-coding or using a different compiler. If the bug is in the hardware the task of eliminating the problem is expotentially more severe. I know of several arithmetic "bugs" in the Unibol RPG compiler for example that were detected with cross-checks. At that point you can be assured that at least _one_ of your answers is wrong, and proceed from there to identify the problem and code around it. I consider the 'bug' to be serious, but easy to work around. I always compile my code with lots of different compilers when it comes to 'C' because I have so many to choose from, since SCO comes with rcc (AT&T) cc (MS) and I use gcc also. Hell you can _never_ be 100% certian of a result in extremely complex operations. The best you can do is regressive tests, and cross checks. I surely wouldn't trust doing a 100x100 matrix division with real numbers by _hand_ to check my machines results :)! > >"Garbage In, Gospel Out." >-- > Hugh LaMaster, M/S 233-18, Email: Please send ASCII documents to: > NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Of course then again, If we were all boosting spaceships into orbit rather than showing a businessman his bottom line, I'm sure the accuracy of the output could get a little more important. Heck, If I'm off 10 grand on the P&L it may only cost someone their job, not their life. Gaining a proper perspective of the problem is also very important. -- Keith Smith Free Usenet News/Newsfeeds Digital Designs (910) 423-4216/7389/7391 PO Box 85 V.34/V.34/V.32 Hope Mills, NC 28348-0085 ... Somewhere in the Styx of North Carolina ...