Date: Thu, 14 Mar 2019 21:54:37 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: segfault on sscanf 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@...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. Going with a solution proposed by Szabolcs Nagy out-of-band (irc), using shlim=-1 to signal EOF status. 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.