dupuy@cs.columbia.edu (Alexander Dupuy) (02/09/89)
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@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 ]]