[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 2 Aug 2016 16:11:30 -0400
From: Rich Felker <dalias@...c.org>
To: Jacob Abrams <jacob@...ver.com>
Cc: musl@...ts.openwall.com
Subject: Re: vprintf.c bug
On Tue, Aug 02, 2016 at 01:02:38PM -0700, Jacob Abrams wrote:
> 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?
Yes. Various places assume that, when the buffer position/limit
pointers are null, it means the FILE is not yet in the right state for
reading/writing. These pointers are loaded from f->buf, so if f->buf
is null, these invariants will be broken.
Also note that, for streams open for reading, there must be at least
UNGET bytes (8 bytes) of writable memory prior to the buffer f->buf
points to; these are not counted in f->buf_size. See stdin.c for an
example. Without this space, ungetc will not work (it will clobber
other data).
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.
