jackm@agcsun.UUCP (Jack Morrison) (11/20/90)
It's a fairly simple matter to write your own handler for the Divide Error interrupt, and have it print out CS:IP. This will at least tell you *where* the error is coming from. -- "How am I typing? Call 1-303-279-1300" Jack C. Morrison Ampex Video Systems 581 Conference Place, Golden CO 80401
grimlok@hubcap.clemson.edu (Mike Percy) (11/21/90)
On porting unix to DOS: my biggest headaches have been caused by word
size differences. I can envision a simple situation where you could get
a divide error (divide by zero causes this, i think).
unix DOS
unsigned int i; /* 32-bits */ unsigned int i; /* 16 bits! */
i = 65535; /* 0xFFFF */ i = 65535; /* 0xFFFF */
i++; /* 0x10000 */ i++; /* 0x0000 !!!! */
printf("%u\n",1/i); /* 1/i == 0 */ printf("%u\n",1/i); /* error!!!! */
Check out this sort of thing. malloc() calls were size_t is 16-bits are
also a major pain to track down.
size_t size; /* 16-bit */
size = 65537; /* 0x0001 */
p = malloc(size); /* got 1 byte!*/
assert(p);
p[65536] = 'a'; /* plowed over memory that wasn't ours, */
/* but looks like it should be! */
While uSoft's C compiler let's you ask for certain word sizes (I think),
Borland's TC (or TC++) don't. Neither generates decent warnings about
these things (maybe 'conversion may lose significant digits' if proper
prototype is in scope, or when doing conversions, but there is no way to
ask the compiler to generate overflow run-time errors/warnings).
"I don't know about your brain, but mine is really...bossy."
Mike Percy grimlok@hubcap.clemson.edu
ISD, Clemson University mspercy@clemson.BITNET
(803)656-3780 mspercy@clemson.clemson.edu