Re: vprintf.c bug

[Rich Felker <dalias@libc.org>]

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