In FreeBSD, "1./0." becomes infinity without calling function, but it becomes "1" with calling function. Using oleo's function divide, the value "#INFINITY" becomes "1". So 1./1. in a cell under oleo becomes be equal to "#INFINITY". Fix: Please apply following patch. How-To-Repeat: Please input "1/1" in a cell. It becomes "#INFINITY".
>>Description: > In FreeBSD, "1./0." becomes infinity without calling function, This is a bug in gcc. 1./0. should be evaluated at runtime, giving the result infinity and setting the IEEE exception flags or causing a SIGFPE, but gcc evaluates it at compile time, giving the result infinitiy and NOT setting the IEEE exception flags. > but it becomes "1" with calling function. I think this is a bug in oleo. Dividing by 0 gives undefined behaviour in ANSI C, so some extension of ANSI C must be used to get defined behaviour. The actual (default) behaviour under FreeBSD is to deliver a SIGFPE. Ignoring the SIGFPE doesn't fix the problem. It gives undefined behaviour in ANSI C and under FreeBSD. The actual behaviour for x/0. under FreeBSD is to give the result x and push `0.' onto the FPU stack. The stack garbage may cause problems later. > Using oleo's function divide, the value "#INFINITY" becomes "1". > So 1./1. in a cell under oleo becomes be equal to "#INFINITY". This seems backwards. 1./1. should not cause any ininities. The port probably needs to use fpsetmask(0) to get defined (IEEE default) behaviour. Bruce
State Changed From-To: open->closed I added a call to fpsetmask() which seems to fix the problem.