Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!indri!lll-winken!uunet!bfmny0!tneff
From: tneff@bfmny0.UUCP (Tom Neff)
Newsgroups: comp.lang.c
Subject: Re: checking for overflow in C
Summary: C is close to an abstract concept of the machine, sort of.
Message-ID: <14312@bfmny0.UUCP>
Date: 7 May 89 03:35:00 GMT
References: <13367@dartvax.Dartmouth.EDU> <1989May6.224226.22085@utzoo.uucp>
Reply-To: tneff@bfmny0.UUCP (Tom Neff)
Organization: ^
Lines: 21

Let me agree with and amplify on Henry Spencer's customarily excellent
remarks, namely that C can't always check things like overflow because
it has to be portable.  There do exist high level languages which cater
to every hardware feature of a family of processors.  On the Intel *86
family PL/M is a perfect example.  Based originally on PL/I Subset (I
will mail a chocolate chip cookie to anyone who ever programmed in
THAT particular late 60s IBM brainchild!!), PL/M has hardware builtins
for virtually everything special about the 8086/88, 286, 386 and now 486.
You use them as functions or procedures in your statements, or sometimes
they are standalone statements like "DISABLE;".  However PL/M is monumentally
non-portable to other architectures, as we know our minimal discomfort
at my employers'.

C on the other hand is signally portable, and incorporates the minimum
of assumptions about how its host processor is going to behave.  Henry
is dead to rights: if your C program needs to worry about integer overflow
in a particular situation, let it check the values beforehand rather than
waiting for the CPU or OS to save its bacon.
-- 
Tom Neff				UUCP:     ...!uunet!bfmny0!tneff
    "Truisms aren't everything."	Internet: tneff@bfmny0.UU.NET