Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!ingr!b11!doyle From: doyle@b11.ingr.com (Doyle Davidson) Newsgroups: comp.windows.x Subject: Re: SIGFPE in miFillSppPoly() Message-ID: <5331@b11.ingr.com> Date: 23 Jun 89 15:15:39 GMT References: <8906211551.AA07986@inria.inria.fr> Organization: Intergraph Corp. Huntsville, AL Lines: 35 In article <8906211551.AA07986@inria.inria.fr>, rob@cetia.UUCP writes: > Occasionally we get Not-a-Number floating point exceptions in ceil() > called from miFillSppPoly(). ... > i have looked at the code, briefly, for miFillSppPoly() > and it does seem possible that the variables xl and xr could be passed > to ceil() without having been initialized. > The algorithm might actually preclude this but i haven't examined it that > closely. > From looking at the code myself (which am and trying not to use since we are having problems with truly meeting the X spec and I think this is the culprit) The only way that I can see xl and xr not being initialized is if the points passed in (which have to be 3 or more) are all linear (and may actually have to be horizontal too i.e. dy=0) which seems rather difficult since it is called from: miWideLine - a line always has width so won't be linear points (0 width will be treated as width 1 if it makes it here) miarc.c - can't say for sure about this one miWideDash - can see any way here since dashes once again have width (did I miss any folks?) So my real question is what are you doing that is causing this weird value? Doyle (mi code is slow, and it doesn't work too) Davidson ------------------------------------------------------------------ Doyle C. Davidson | Intergraph Corp. | These comments are... Workstation Graphics Standards | 1 Madison Industrial Park | \\ / Huntsville, AL 35806 | \\/ (205) 772-2000 | /\\ clusively my own. | / \\ ..!uunet!ingr!b11!doyled!doyle | ------------------------------------------------------------------