Hi Jim, > >> freebsd$ ./printf %.2147483647f 1 > >> Segmentation fault (core dumped)
I reproduce on NetBSD 3.0, both with the system's printf program and with the coreutils printf. It dumps core for width 50000000 but not for width 10000000. Therfore I think it's an unhandled out-of-memory condition. > I think I'll have to resort to using a moderately large width, yet > with limited virtual memory, e.g., via ulimit -v 10000. Good idea! > Even with the following patch, and with printf-posix enabled, it > still fails, this time via libc's snprintf. Yes, so far, when it appears to work, the vasnprintf just passes the width to the underlying system's snprintf. But the code is already prepared for handling the width on its own. > +2007-10-30 Jim Meyering <[EMAIL PROTECTED]> > + > + printf-posix: Depend on vprintf, not vfprintf. > + * modules/printf-posix: Otherwise, applications could use a > + buggy system vprintf, rather than our replacement. This is not right. The lib/printf.c function makes a call to vfprintf, therefore depending on vfprintf-posix is the right thing. It's the xprintf.c code which calls vprintf(), bypassing printf(). Since this is a detail that the gnulib user should not know about, we should introduce a module 'xprintf-posix' that causes xprintf to have POSIX semantics for the formatted output. It will depend on xprintf and vprintf-posix. I'll do it later today if you don't beat me to it. Bruno
