[M3devel] bugs in hand.c division

[Jay K]

Understood. I put that back -- depending on C compiler flags,
LONG_MIN / -1 will either be LONG_MIN or trap.
Trap seems reasonable.
Though Modula-3 might mandate the consistent LONG_MIN?
Or leave it implementation defined?


The real bugs here were:
  LONG_MIN / negative (other than -1) was returning positive 
  possibly long long problem with K&R style, I'm pretty sure 
  possibly slightly fragile code wrt signed overflow. 


   funny thing is though, the reason I went looking into this
   was because mailing list threads lead me to believe my
   functions that are meant to look for overflow might be
   broken by the optimizer; it doesn't seem to notice them 
   but the funny stuff m3_div was doing, the optimizer 
   sees opportunity in and warns..so I started writing
   something using unsigned math, which isn't subject
   to such fragility, started testing it by comparison
   to the existing..found the existing to be wrong 


  I didn't really understand the code that was there.
  
But from the spec and behavior I could see -- round down negative results.
   Which you can do by roughly - ((abs(a) + abs(b) - 1) / abs(b))
   Round up the positive result.

 - Jay


> Date: Sun, 17 Jan 2010 08:49:45 +0100
> From: roland.illig at gmx.de
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] bugs in hand.c division
> 
> Jay K schrieb:
> > The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
> > What is that supposed to equal?
> > For any version that doesn't "crash", the result is LONG_MIN.
> 
> That's the best result one can get besides throwing an exception. With 
> unlimited integers, the result would be LONG_MAX + 1, which equals 
> LONG_MIN (modulo 2^BITSIZE(LONG)) when you are using two's complement 
> arithmetics.
> 
> Roland
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/644bba0e/attachment-0002.html>