Update of bug #50221 (project gforth):
Status: Need Info => Confirmed
_______________________________________________________
Follow-up Comment #3:
Yes, it's definitely not a NaN coming out of the computation:
1 53 lshift 1- s>f 1 53 lshift s>f f/ fdup f= .
prints -1 (for a Nan we would see 0).
And it is really the FP->String conversion (REPRESENT on the
Forth level, ecvt_r on the C level). It works with the ecvt_r
from glibc 2.19 on AMD64. Unfortunately it does not work
reliably with our own ecvt_r replacement, either:
2e0 -53e0 f** fconstant eps
1e0 eps f- pad 20 represent .s cr pad 20 dump
This produces an "invalid" result (and the ":" in the string).
So I consider this to be a bug in MacOS X's ecvt_r and in our own
ecvt_r replacement; and ideally we should be checking for this bug in
our configure script so that our then-fixed ecvt_r replacement is used
instead of the broken MacOS X ecvt_r.
Thank you for the bug report.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?50221>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
bug-gforth mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gforth
