Re: [PATCH] Re: buggy vfprintf makes printf(1) segfault on freebsd 5.0

[Bruno Haible]

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  <address@hidden>
> +
> +     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