Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!emory!hubcap!grimlok
From: grimlok@hubcap.clemson.edu (Mike Percy)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Strange results with Turbo C program (Divide Error)
Message-ID: <11761@hubcap.clemson.edu>
Date: 20 Nov 90 21:53:22 GMT
References: <29857@boulder.Colorado.EDU> <39630@ucbvax.BERKELEY.EDU> <1990Nov19.142112.12313@abcfd20.larc.nasa.gov> <866@agcsun.UUCP>
Organization: Clemson University, Clemson, SC
Lines: 34


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