fix behavior of gets when input line contains a null byte
authorRich Felker <dalias@aerifal.cx>
Wed, 13 Feb 2019 23:48:04 +0000 (18:48 -0500)
committerRich Felker <dalias@aerifal.cx>
Wed, 13 Feb 2019 23:48:04 +0000 (18:48 -0500)
commitb2020571f07beaa9873ef0e5ade456b57b589042
treec490136176fecac7cc65c7bde05d02d77b7cb060
parent099b89d3840c30d7dd962e18668c2e6d39f0c626
fix behavior of gets when input line contains a null byte

the way gets was implemented in terms of fgets, it used the location
of the null termination to determine where to find and remove the
newline, if any. an embedded null byte prevented this from working.

this also fixes a one-byte buffer overflow, whereby when gets read an
N-byte line (not counting newline), it would store two null
terminators for a total of N+2 bytes. it's unlikely that anyone would
care that a function whose use is pretty much inherently a buffer
overflow writes too much, but it could break the only possible correct
uses of this function, in conjunction with input of known format from
a trusted/same-privilege-domain source, where the buffer length may
have been selected to exactly match a line length contract.

there seems to be no correct way to implement gets in terms of a
single call to fgets or scanf, and using multiple calls would require
explicit locking, so we might as well just write the logic out
explicitly character-at-a-time. this isn't fast, but nobody cares if a
catastrophically unsafe function that's so bad it was removed from the
C language is fast.
src/stdio/gets.c