On Sat, Nov 12, 2011 at 03:19, Dave Hart <h...@ntp.org> wrote: > Excellent. I assume the stack trace is from ntpd 4.2.6p3. I think > you've found a bug in your system's libc dtoa() exposed by its > snprintf(s, " %.2f", ...). I believe you will not be able to > reproduce the bug using 4.2.7, as that version of ntpd uses > C99-snprintf [1] if the system snprintf() is not C99-compliant. > C99-snprintf's rpl_vsnprintf() does not use dtoa(), it hand-rolls the > double-to-ascii conversion. Below is the code in ntpd. NTP_SHIFT is > 8. I claim the ntpd code is correct and your system's dtoa() and > thereby snprintf() of double (floating point) is subject to infinite > looping for some values.
I was confused. Thinking of the antique hardware involved, I was assuming wrongly that the system-provided snprintf() was not C99-compliant. In fact, the antique is running modern NetBSD 5.x, which undoubtedly does provide a C99 snprintf(). But wait, there's more. I was also probably wrong in saying that this is a bug in 32-bit SPARC NetBSD 5.x dtoa(). That code is likely quite mature and such a bug would have been found before now. My hunch is a hardware bug, but I'll pursue that on the port-sp...@netbsd.org list. I will report back here once it's resolved, if Mr. Carver does not. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
