I've recently had the need to review glibc's vfprintf code. During the
process I discovered that no testcase for bug #13446 was ever installed.
The original testcase in #13446 utilizes the printf hooks mechanism; the
system where I needed the problem fixed & tested pre-dates printf hooks,
so I mangled the existing stdio-common/bug23.c test to expose the memory
allocation bug in #13446.
The new test looks fine and since it's simpler than the one in the bug
attachment that's better anyway. But real good trick finding a system
that "pre-dates printf hooks" since IIRC the printf.h interface
actually pre-dates the %n$ support by a few years (and it might well
pre-date Linux, in fact).
On 05/24/2012 12:36 PM, Roland McGrath wrote:
> The new test looks fine and since it's simpler than the one in the bug
> attachment that's better anyway.
But real good trick finding a system
> that "pre-dates printf hooks" since IIRC the printf.h interface
> actually pre-dates the %n$ support by a few years (and it might well
> pre-date Linux, in fact).
More correctly, the system continues to use the fast path even with a
printf hook installed. It's missing this hunk:
/* Use the slow path in case any printf handler is registered. */
if (__builtin_expect (__printf_function_table != NULL
|| __printf_modifier_table != NULL
|| __printf_va_arg_table != NULL, 0))
On 05/24/2012 02:05 PM, David Miller wrote:
> From: Jeff Law<[hidden email]>
> Date: Thu, 24 May 2012 12:20:24 -0600
>> - bug-vfprintf-nargs tst-long-dbl-fphex tst-fphex-wide tst-sprintf3
>> + bug-vfprintf-nargs tst-long-dbl-fphex tst-fphex-wide tst-sprintf3 \ bug25
> That looks really odd to say the least ;-)
Not sure how that happened. Regardless, it's fixed.