Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!ima!mirror!xanth!kent From: kent@xanth.UUCP Newsgroups: comp.lang.c Subject: C and overflow anomolies Message-ID: <820@xanth.UUCP> Date: Sat, 11-Apr-87 02:08:46 EST Article-I.D.: xanth.820 Posted: Sat Apr 11 02:08:46 1987 Date-Received: Sun, 12-Apr-87 01:04:59 EST References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP> <995@wanginst.EDU> Reply-To: kent@xanth.UUCP (Kent Paul Dolan) Distribution: world Organization: Old Dominion University, Norfolk Va. Lines: 99 Keywords: C overflow anomolies execution order parentheses Summary: There is an occassional need for execution order control to prevent overflows. In article <995@wanginst.EDU> mckeeman@wanginst.EDU (William McKeeman) writes: >I am a bit frustrated by people talking past each other on this topic. The >order of evaluation rules in C are a blanket over several subproblems. >Conclusion: when making a pitch for a better C definition rule, identify >which of the problems: > unrestricted optimization > overflow anomalies > roundoff anomalies > side effect anomalies >it is designed to solve. If you don't intend for your rule to have >language-wide implications, state the limited area of application. >-- >W. M. McKeeman mckeeman@WangInst >Wang Institute decvax!wanginst!mckeeman >Tyngsboro MA 01879 I agree that this is an excellent idea, and, being nothing if not opinionated, and having freely confessed my disenchantment with C in its present state in this forum previously, I will start this discussion off with four new subjects corresponding to (Mr., Mrs., Miss, Ms., Dr., (?)) McKeeman's plan, and then sit back and read the responses. A few times in 26 years of coding, I have found myself working at the limits of a data type, and having to rearrange code to assure that overflow or underflow did not take place, during a sound, but not robust calculation. Where control of execution order was needed, nothing else would do. A previous poster has noted that a compiler writer who is on an optimization spree (not meant to be derogatory, I have a lot of respect for this skill, and spent a long bar evening listing to some justifiable bragging by one of the practicioners of this bit of arcana) will not respect anything you can do to force a certain code order, since s/he feels free to rearrange statements, elide temporaries, rearrange loops, rearrange blocks, reduce strength (change your multiplies to adds, for example), and recent publications suggest that separate compilation may not be good enough, either, to prevent unexpected interactions of two pieces of code which were certainly separate in the programmer's mind. Mathematical programmers (and, after its 30 years in continuous use for the purpose, a great many of these are FORTRAN users) who turn to C for whatever reason are occassionally astonished by the disrespect of C compilers for the parentheses the programmer just so carefully included to control execution order. Perhaps the proper response is to tell the mathematical programmer to look elsewhere for a language to use, but the problem exists for the less demanding user, too. C is famous (notorious) for its variety of integer variables, signed and unsigned, and byte, word, and double word (and other) sizes make the creation of portable code a task for the cautious and insightful programmer. The utility of these many integer sizes is manifest; it allows systems tables (structures) to be created with a minimum size by using just the right mix of integer variable sizes. But now, if arithmetic must be done with these variables, the problem of overflow arises. One solution is surely to pick the next larger integer size when overflow threatens. Usually, however, if the integer size is chosen to match the range of the data to be stored, this is an inappropriate and wasteful choice, compared to arranging the arithmetic in the proper order to avoid overflow. To do this, the compiler must be able to understand when the programmer wants the code executed exactly as written, and leave it alone. The ANSI C dpANS, I understand, has chosen to overload the unary plus with this task. I have two problems with this. First it is {counterintuitive, ugly,unmathematical} (pick one). I have noted earlier, that to the user coming from a secondary school environment, the unary plus is a no-op, just as s/he learned in algebra class. It really trashes out the appearance of an expression containing it (although C is already in the top five, in the running for world's ugliest major language) (need I mention that is one of the opinions promised above?). ;-) Stray operators floating around don't look much like the mathematical equations to which the new user is presumably accustomed. Second, this may provide insufficient or inappropriate granularity of control against the optimizing compiler. I may need to control the order of execution of a series of statements which the compiler may decide to rearrange. The unary plus doesn't cut it here, but the compiler author has promised to look everywhere for optimizations. How do I stop the code from exercising optimization where it is dangerous to the success of the program, without turning it off where it is harmless or beneficial? I think the standard should include a better, prettier method of control of optimization scope and degree. Comments? Kent. -- The Contradictor Member HUP (Happily Unemployed Programmers) // Also // A Back at ODU to learn how to program better (after 25 years!) \\ // Happy \// Amigan! UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Copyright 1987 Kent Paul Dolan. How about if we keep the human All Rights Reserved. Author grants race around long enough to see retransmission rights recursively only. a bit more of the universe?