fix crash/out-of-bound read in sscanf
authorRich Felker <dalias@aerifal.cx>
Fri, 15 Mar 2019 00:52:18 +0000 (20:52 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 15 Mar 2019 00:52:18 +0000 (20:52 -0400)
commit8f12c4e110acb3bbbdc8abfb3a552c3ced718039
tree27460bc072add4c242b8524057fa6f49db8238bb
parentc62dfe61611cee4b9b2667e1aec8a20385bc5c55
fix crash/out-of-bound read in sscanf

commit d6c855caa88ddb1ab6e24e23a14b1e7baf4ba9c7 caused this
"regression", though the behavior was undefined before, overlooking
that f->shend=0 was being used as a sentinel for "EOF" status (actual
EOF or hitting the scanf field width) of the stream helper (shgetc)
functions.

obviously the shgetc macro could be adjusted to check for a null
pointer in addition to the != comparison, but it's the hot path, and
adding extra code/branches to it begins to defeat the purpose.

so instead of setting shend to a null pointer to block further reads,
which no longer works, set it to the current position (rpos). this
makes the shgetc macro work with no change, but it breaks shunget,
which can no longer look at the value of shend to determine whether to
back up. Szabolcs Nagy suggested a solution which I'm using here:
setting shlim to a negative value is inexpensive to test at shunget
time, and automatically re-trips the cnt>=shlim stop condition in
__shgetc no matter what the original limit was.
src/internal/shgetc.c
src/internal/shgetc.h