Re: [avr-gcc-list] libm trouble

[Peeter Vois]

The hard thing is that the nan dresult is easy to happen and checking
it each step is almost impractical. I was investigating the asm code in
CVS regarding this issue and I did not notice any serious errors. Still
some things did remain unclear yet: the nan routine has lots of ifdef
selections, which ones were used during compiling: there was an exponent
check against 0 and rjump 1f which was probably meant as jump to label 1
forward, but 1f can be handled as a hexadecimal number aswell and in
that case the program will make wrong jump. Unpredicted results may
happen.

Best Regards ...
Peeter Vois

Ühel ilusal kenal päeval Mon,  9 Aug 2004 09:50:12 +0200 (MET DST)
address@hidden (Joerg Wunsch) kirjutas:

> Peeter Vois <address@hidden> wrote:
> 
> > The answer is nan, but something strange will
> > happen besides it: like erasing the RAM area.
> 
> The Inf and NaN handling of the current library is alpha quality at
> best, and far away from being compatible with current standards.  I
> wouldn't trust it more than comparing the result of an operation
> against NaN, in order to escape then.
> 
> Also, since there are no options to signal something, it's not even
> possible to go the `historic' route of trapping arithmetic errors.
> 
> -- 
> J"org Wunsch                                         Unix support engineer
> address@hidden       
> http://www.interface-systems.de/~j/
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list