From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13976 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: segfault on sscanf Date: Thu, 14 Mar 2019 21:54:37 -0400 Message-ID: <20190315015437.GK23599@brightrain.aerifal.cx> References: <20190314104617.711ac7d8@faultier2go> <20190314162814.GI28106@voyager> <20190314165335.GJ28106@voyager> <20190314181919.GJ26605@port70.net> <20190314183812.GK28106@voyager> <20190314194933.GK26605@port70.net> <20190314223415.GH23599@brightrain.aerifal.cx> <20190314224358.GM26605@port70.net> <20190314225203.GJ23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="168510"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13992-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 15 02:54:54 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h4c3g-000hhc-GL for gllmg-musl@m.gmane.org; Fri, 15 Mar 2019 02:54:52 +0100 Original-Received: (qmail 26349 invoked by uid 550); 15 Mar 2019 01:54:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26331 invoked from network); 15 Mar 2019 01:54:49 -0000 Content-Disposition: inline In-Reply-To: <20190314225203.GJ23599@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13976 Archived-At: 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 [2019-03-14 18:34:15 -0400]: > > > On Thu, Mar 14, 2019 at 08:49:34PM +0100, Szabolcs Nagy wrote: > > > > * Markus Wichmann [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