Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.lang.c
Subject: Re: checking for overflow in C
Message-ID: <1027@philmds.UUCP>
Date: 10 May 89 13:23:27 GMT
References: <13367@dartvax.Dartmouth.EDU> <1989May6.224226.22085@utzoo.uucp> <8143@june.cs.washington.edu>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 23

In article <8143@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes:
|henry@utzoo.uucp (Henry Spencer) writes:
|> C unfortunately has to be close to the hardware of a wide variety of
|> machines.  There is no consensus on whether the hardware checks for overflow
                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> or not.  C generally prefers to reflect the underlying hardware rather
|> than trying to hide it, so this lack of consensus shows to the programmer.
|
|If there is not a consensus, there is certainly an overwhelming majority!
|I know the assembly languages of half a dozen machines, and they all
            ^^^^^^^^^^^^^^^^^^
|include overflow checks.
         ^^^^^^^^^^^^^^^
|				Kenneth Almquist

Unless I'm way off, Henry was talking about hardware checks, to
enforced by the hardware (causing exceptions or traps or similar to
occur whenever they're violated). The overflow checks in an assembly
language, as Kenneth referred to, are compiler generated/programmed in,
are software based checks and thus could/can be left out (I think he
meant either explicitly or implicitly testing the status word).

    Leo.