Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Aug 2016 13:02:38 -0700
From: Jacob Abrams <>
To: Rich Felker <>
Subject: Re: vprintf.c bug

I am on an embedded system with minimal OS so I just defined my own
stdout and stderr that redirect to my own UART output function:

static FILE uart_stdout = {
.fd = 1,
.lbf = '\n',
.flags = F_PERM | F_NORD,
.write = uart_write,
.lock = 1,

static FILE uart_stderr = {
.fd = 2,
.lbf = EOF,
.flags = F_PERM | F_NORD,
.write = uart_write,
.lock = -1,

You are saying that buf must point to a memory location but that
buf_size may be zero?


On Tue, Jul 26, 2016 at 8:17 PM, Rich Felker <> wrote:
> On Tue, Jul 26, 2016 at 03:25:40PM -0700, Jacob Abrams wrote:
>> I believe there is a small bug in vfprintf.c
>> I had to change the if statement from
>>     ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
>>     if (saved_buf) {
>> to
>>     ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
>>     if (f->buf == internal_buf) {
>> Because the saved_buf may be NULL which will result the internal
>> buffer being used but the file not being reset properly after the call
>> to printf_core. This was discovered while using MUSL v1.1.4 on an OS
>> other than Linux.
> Where do you get a FILE with a null f->buf? While it's not written
> down anywhere, that breaks a contract expected several other places in
> the stdio implementation. If you're trying to use vfprintf.c outside
> of musl I think you probably need to disable/remove this buffer
> replacement code, which would be poking at the internals of another
> stdio implementation in a likely-invalid way.
> Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.