[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJJ2OC2G_a1xrRJqzt1dsyUxZLio5a45NFkQawitoF7ghMv5vQ@mail.gmail.com>
Date: Tue, 2 Aug 2016 13:02:38 -0700
From: Jacob Abrams <jacob@...ver.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
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?
Jacob
jacob@...ver.com
On Tue, Jul 26, 2016 at 8:17 PM, Rich Felker <dalias@...c.org> 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.
