Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.lang.c Subject: Re: Numeric comparisons Message-ID: <56@opus.UUCP> Date: Wed, 18-Sep-85 02:32:18 EDT Article-I.D.: opus.56 Posted: Wed Sep 18 02:32:18 1985 Date-Received: Fri, 20-Sep-85 04:06:17 EDT References: <10176@ucbvax.ARPA> <5118@mit-eddie.UUCP> <693@terak.UUCP> <160@graffiti.UUCP> Organization: NBI,Inc, Boulder CO Lines: 26 > > Compiler users note -- if your compiler gives the wrong results, the > > compiler writer might not be completely at fault. Many early CPU > > chips (8080A, Z80, 6502, etc.) did comparison by subtraction, and a > > compiler would have had to generate extra code to test for Overflow > > in order to get the correct result. Oomph! Point of philosophy, yer honner--it is NOT the job of the compiler writer to transmit shortcomings of the processor into language problems. If the chip does the comparison "wrong" (in some cheap way), the compiler writer needs to sort it out so that the language implementation gives the right answer. I once complained about the implementation of certain comparison operations in a well-known language on a well-known processor--the problem was that it was possible to find values a, b, c such that all of a