Re: segfault on sscanf

[Rich Felker <dalias@libc.org>]

On Thu, Mar 14, 2019 at 06:52:03PM -0400, Rich Felker wrote:
> On Thu, Mar 14, 2019 at 11:43:58PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2019-03-14 18:34:15 -0400]:
> > > On Thu, Mar 14, 2019 at 08:49:34PM +0100, Szabolcs Nagy wrote:
> > > > * Markus Wichmann <nullplan@gmx.net> [2019-03-14 19:38:12 +0100]:
> > > > 
> > > > > On Thu, Mar 14, 2019 at 07:19:19PM +0100, Szabolcs Nagy wrote:
> > > > > > i think __shgetc should ensure f->rpos == f->shend on EOF
> > > > > 
> > > > > What about shunget(), though? Currently, if shgetc() returns EOF, at the
> > > > 
> > > > i meant f->rpos == f->shend == 0.
> > > 
> > > Changing f->rpos is not valid here; it would corrupt the state of the
> > > FILE for furher use after the shgetc phase is done. This is especially
> > > important if we reached the code due to shlim being hit, but I think
> > > it also matters for __uflow failing; normally the FILE is left in read
> > > mode, with rpos and rend pointers valid. If we were going to zero
> > > rpos, we would also have to zero rend, taking it out of read mode, but
> > > this does not seem desirable.
> > > 
> > > Rather, I think f->shend should be set to f->rpos, not 0. Does this
> > > sound right?
> > 
> > makes sense, but then needs to be a new way to check
> > for EOF instead of f->shend==0.
> 
> Oh, yes, I forgot about that -- shunget uses shend status rather than
> the character to unget (which it can't see) to decide whether to act.
> We can't use the file EOF status because it could be a pseudo-EOF due
> to shlim. It might need a new field.

Going with a solution proposed by Szabolcs Nagy out-of-band (irc),
using shlim=-1 to signal EOF status.

Rich