On Tue, Feb 7, 2012 at 18:46, Dave Hart <[email protected]> wrote: > On Tue, Feb 7, 2012 at 18:38, A C <[email protected]> wrote: >> On 2/7/2012 10:21, Dave Hart wrote: >>> Thanks for the heads-up. Assuming by "the C99 flag" you mean it was >>> configured using --enable-c99-snprintf, that flag didn't "take". If >>> it had, you wouldn't be using libc's snprintf, you'd be using libntp's >>> rpl_snprintf() which would have called rpl_vsnprintf(), and based on >>> previous experience, it wouldn't have resulted in an infinite loop. >> >> >> I was wondering about that. I recompiled it twice with that configure >> option. Any idea why it would have been ignored this time? I'll rebuild it >> and see what happens. > > No idea. However, you don't have to wait for it to hang to see if the > option is working as intended. After building, look in the build tree > for config.h and grep it for rpl_snprintf. You should see #define > snprintf rpl_snprintf, otherwise it didn't take. If it didn't, email > me the config.log.
It appears to be a bug in code I added to sntp/m4/snprintf.m4 (from the C99-snprintf package, but not yet integrated upstream). See http://bugs.ntp.org/2134 for details. Thanks the agcarver for quickly helping identify it, and here's hoping it's the reason his NetBSD 5.1/sparc ntpd has been going haywire with its known-bad dtoa() used by its libc *snprintf routines. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
