From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3120 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: scanf requirements not met? Date: Sat, 20 Apr 2013 12:51:20 -0400 Message-ID: <20130420165120.GK20323@brightrain.aerifal.cx> References: <20130405015254.GA4997@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366476690 6436 80.91.229.3 (20 Apr 2013 16:51:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2013 16:51:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3124-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 20 18:51:34 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UTb0f-0003ke-UD for gllmg-musl@plane.gmane.org; Sat, 20 Apr 2013 18:51:34 +0200 Original-Received: (qmail 32554 invoked by uid 550); 20 Apr 2013 16:51:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32546 invoked from network); 20 Apr 2013 16:51:32 -0000 Content-Disposition: inline In-Reply-To: <20130405015254.GA4997@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3120 Archived-At: On Thu, Apr 04, 2013 at 09:52:55PM -0400, Rich Felker wrote: > Hi all, > > In consideration of adding the 'm' modifier for scanf and looking at > how it's supposed to handle malloc failure, I believe the current > implementation may be getting some things wrong. Seeing that it > defined malloc failure as a "conversion error": > > If there is insufficient memory to allocate a buffer, the function > shall set errno to [ENOMEM] and a conversion error shall result. > > I noticed that this was not either of the "failures" defined for > scanf: input or matching. The text "conversion error" does not occur > elsewhere, but the ERRORS section does specify: > > If any error occurs, EOF shall be returned, and errno shall be set > to indicate the error. Searching again, I can no longer find the text "if any error" in the specification for scanf. It looks like TC1 has been applied to the html version of POSIX, and the text I had cited above, which conflicts with the requirements of ISO C, has been corrected such that an error return only happens if the error occurs before the first conversion. In short, we had it right and POSIX had it wrong. There may be one remaining issue: it's not clear to me whether scanf can return EOF after a successful match for which assignment was suppressed with the * modifier. Such matches do not contribute to the count returned, but by a strict reading, they seem to contribute to the requirement to return 0 rather than EOF. > If the function returns EOF, any memory successfully allocated for > parameters using assignment-allocation character 'm' by this call > shall be freed before the function returns. With TC1 applied, this text is mostly irrelevant; it only applies to the first conversion. Rich