Path: utzoo!attcan!uunet!crdgw1!jupiter!kassover
From: kassover@jupiter.crd.ge.com (David Kassover)
Newsgroups: comp.graphics
Subject: Re: Fracturing self-intersecting polygons into trapezoids
Keywords: polygon,intersection,double precision, accuracy
Message-ID: <5658@crdgw1.crd.ge.com>
Date: 1 Mar 90 18:18:10 GMT
References: <20408@versatc.versatec.COM> <5637@crdgw1.crd.ge.com>
Sender: news@crdgw1.crd.ge.com
Organization: Aule-Tek, Inc.
Lines: 29

In article <5637@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes:
...
That's me...

>It begins to be not hardly worth the effort.  Perhaps you can get
>permission to implement THESE ROUTINES in local assembler and
>call them from your main program.

I checked with one of my C/Unix gurus.  He assured me that
*maybe* you could trap one of the unix standard signals for
integer overflow, but you would be advised to write a short
experiment to verify it.
 
Further, you have access to the bitwise representation of your
int's, and therefore moderately simple to check for overflow.
 
The sizeof function will return the length of an int in bytes.
The hard part is knowing how many bits/byte.  It seems, from an
examination of K&R, that you have to glean that information from
the underlying platform documentation, and build it into your
procedures.

I know of one architecture which has 64 bit words, 8 bit bytes, but uses only
56 bits out of the 64 for integers.  (Don't laugh, this way they
can use the floating point hardware for integer operations)

Let us know how it all comes out.
 
Dave