Integer Overflow (was: The Moderator Always Gets the Last Word)

[Alexander Dupuy]

As Matt Goheen said, "The problem with that advice is that people tend to
think that they are absolutely correct, even when they aren't, until
someone proves otherwise (and sometimes, even after that)."

While Phil was right (under a strict interpretation of the question) when
he said that integer overflow cannot be detected in C, he was way off base
when he said "there is no way to convert an overflow into a Unix signal:
the 680x0 doesn't support that sort of behavior."

In fact, there is a special 68000 instruction, TRAPV, whose only purpose
is to cause a trap if the overflow (V) condition code in the status
register is set.  This allows C programs to detect overflow without
special compiler or library support, simply by placing asm("trapv")
statements after critical integer arithmetic operations (this does require
compiler support for inline assembler instructions, of course).  Under
SunOS 3.5 and 4.0, the trapv causes a SIGFPE signal to be sent to the
process, with a subcode of FPE_TRAPV_TRAP.

It is apparently possible to cause integer overflows to trap on the VAX
and SPARC architectures as well, based on the contents of the 4.0
<sys/signal.h>.  This may be done with a special mode - I'm not sure.

On the subject of our moderator's comments, I'll say just this: while the
intention of reducing duplicate explanations to simple questions is
laudable, there is no requirement that if duplicate answers are sent, all
of them be published.  It may be more work to sift through a dozen replies
to pick the best one, and post only that one, but when the moderator has
several answers to choose from (including his own) it is more likely that
only one (correct) answer will be published, which is what we would all
like to see.

However, I would like to say that even with the inaccurate comments, the
overall quality of Sun-Spots has increased lately, primarily because of
shorter response time.  I appreciate the work involved and my thanks go to
you.

@alex
 -- 
inet: dupuy at cs.columbia.edu
uucp: ...!rutgers!cs.columbia.edu!dupuy

[[ There is no way to set up the 680x0 to *automatically* generate an
exception when an integer overflow occurs (which is, of course, what I
meant).  To use TRAPV for this, one would have to be inserted after
*every* arithmetic instruction.  This isn't quite the same thing.  So that
there is no further misunderstanding, I will be excessively precise:  the
Digital VAX has a IV (Integer oVerflow) bit in the PSW (Processor Status
Word), but the 680x0 has no equivalent.  From the VAX Architecture
Handbook:  "Bit 5 is the Integer oVerflow trap enable; when set, it causes
an integer overflow trap after an instruction which produced an integer
result that could not be correctly represented in the space provided...."
--wnl ]]