🚀 go-pugleaf

In article <4cs460$d6e@news.informix.com> Daniel Wood
<dwood@informix.com> writes:

|> I totally understand what you are doing in the above but this would have to
|> be the ultimate in a cheap out for a vendor.  SCO could claim that before
|> ever looking at a test case containing a suspected compiler bug that every
|> arithmetic calculation would have to first have a test similar to the above
|> to protect against overflow/underflow.  Does an appropriate "SAFE TEST" exist
|> for multiple.

Yes, but you have to do the actual operations using the absolute
values, and then generate the sign yourself.  Basically, for positive
values, x * y will overflow if and only if x > y / INT_MAX.  (You must
use positive values because division with negative values is not well
defined, and if the result will be negative, the test must use
-INT_MIN instead of INT_MAX.)

|> Has anyone actually seen a real production program where every
|> calculation was protected against overflow/underflow.

Yes.  In the late 80's I worked on a Basic interpreter where all
overflows generated a run-time exception.  Given the overhead of the
interpreter, and the type of applications that were being written in
Basic, the overhead for checking was perfectly acceptable.  Although
the code was written before ANSI introduced the concept of `undefined
behavior', it was written such that an integer overflow could never
occur, even in results that would later be thrown out (because of
error detection).  It's not particularly hard; all that is needed is
1) that the requirements require it, and 2) that the performance
penalty is acceptable.

    [...]
|> Do any machines exist which actually explode when you add two number together
|> such that the result would exceed MAXINT? :-)  Get pratical!

Explode, perhaps not.  But a core dump would be an appropriate
behavior.  Most programs don't check for overflow on the grounds that
garbage in/garbage out is an acceptable modus operandi.  Practically,
overflow cannot occur for reasonable values of input, and they
consider undefined behavior acceptable for unreasonable user input
(given that in reality, we know that the undefined behavior won't
actually cause loss of life or property).  In such cases, overflow
represents a failure in the model; it would be nice to have the
program fail if the model fails, rather than simply give wrong
results.

|> I am particularly interested in the answer to my "safe multiply" question
|> above.  It would be quite funny to find that there is actually no way to
|> create, in a practical way, a safe c program that used multiple if the
|> standard was followed to the letter of the law.  I have thought of a way
|> but it would be alot more involved then the sum_overflow() check above.

It is somewhat more complicated than the above.

In most cases, the correct solution is *not* to test each individual
operations, but to validate all input values for `reasonableness', and
then prove that overflow cannot occur for reasonable values of input.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone