fix major scanf breakage with unbuffered streams, fmemopen, etc.
authorRich Felker <dalias@aerifal.cx>
Sat, 22 Jun 2013 21:11:17 +0000 (17:11 -0400)
committerRich Felker <dalias@aerifal.cx>
Sat, 22 Jun 2013 21:11:17 +0000 (17:11 -0400)
commitc20804500deebaabc56f383d48dd1ac77dce8349
tree8123af90cd923e12dc864fcd291926ef85aa9f83
parenta494171a5a2778fc7b4d24d673d950f3e9864063
fix major scanf breakage with unbuffered streams, fmemopen, etc.

the shgetc api, used internally in scanf and int/float scanning code
to handle field width limiting and pushback, was designed assuming
that pushback could be achieved via a simple decrement on the file
buffer pointer. this only worked by chance for regular FILE streams,
due to the linux readv bug workaround in __stdio_read which moves the
last requested byte through the buffer rather than directly back to
the caller. for unbuffered streams and streams not using __stdio_read
but some other underlying read function, the first character read
could be completely lost, and replaced by whatever junk happened to be
in the unget buffer.

to fix this, simply have shgetc, when it performs an underlying read
operation on the stream, store the character read at the -1 offset
from the read buffer pointer. this is valid even for unbuffered
streams, as they have an unget buffer located just below the start of
the zero-length buffer. the check to avoid storing the character when
it is already there is to handle the possibility of read-only buffers.
no application-exposed FILE types are allowed to use read-only
buffers, but sscanf and strto* may use them internally when calling
functions which use the shgetc api.
src/internal/shgetc.c