[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Mar 2019 18:52:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: segfault on sscanf
On Thu, Mar 14, 2019 at 11:43:58PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-03-14 18:34:15 -0400]:
> > On Thu, Mar 14, 2019 at 08:49:34PM +0100, Szabolcs Nagy wrote:
> > > * Markus Wichmann <nullplan@....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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
