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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,18069d15345a10c8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-14 17:16:39 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Modulus and Remainder operations (Was Re: Help with a bit of C code) Date: 13 Oct 1994 16:59:50 -0400 Organization: Courant Institute of Mathematical Sciences Message-ID: <37k746$50s@gnat.cs.nyu.edu> References: <1994Oct11.161048.1058@nosc.mil> <37er8t$oh0@watnews1.watson.ibm.com> <1994Oct13.181350.10997@nosc.mil> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-10-13T16:59:50-04:00 List-Id: There is a big difference between the different kinds of "errors", and chief among them is that some of them are not considered errors. Implementation dependent means that the effect is a function of the implementation, but the implementation is not required to document what it does. It is not in any sense an error to write such code, but its effect is non-deterministic, and so it would be wrong in some sense to "rely" on a particular behavior, whatever that means. The fact that it is impossible to formally characterize is why we have abandoned statements like "relying on xxx is erronoues", such statements are semantically vacuous. Implementation defined means that the effect must be defined by the implementation. The effect is entirely deterministic for a given implementation, and there is nothing WHATSOEVER wrong in relying on the documented behavior. Of course the code is potentially non-portable, but there are many ways to write non-portable code, and many situations in which it is quite legitimate to write non-portable code (e.g. in device drivers). Writing non-portable code when you should be writing portable code is a mistake, but is not somehow "wrong" at the language level. Erroneous means that the compiler is free to do anything at all, and we definitely intend to imply that erroneous execution is an error in the general sense, to be avoided. While it can be quite legitimate to write a program that exploits an implementation dependent or implentation defined feature, it is never legitimate to write an erroneous program, and the compiler is free to for example raise program error (or worse) if it detects the error (or if it doesn't). A bounded error is a special case of erroneousness where the possible things the compiler can do are limited. IN purely formal terms it is no different from a non-deterministic behavior. However, the non-formalizable, but very important difference, is that it is definitely considered an error, essentially as bad as writing erroneous programs, to write programs containing bounded errors. The reason we go to the trouble of limiting the damage is to (a) make programs easier to debug and (b) attempt to limit the damage that occurs if a program accidentally runs into a bounded error.