From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3046 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: scanf requirements not met? Date: Thu, 4 Apr 2013 21:52:55 -0400 Message-ID: <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 1365126793 11150 80.91.229.3 (5 Apr 2013 01:53:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Apr 2013 01:53:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3047-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 05 03:53:41 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 1UNvqO-0008Ms-JT for gllmg-musl@plane.gmane.org; Fri, 05 Apr 2013 03:53:32 +0200 Original-Received: (qmail 15967 invoked by uid 550); 5 Apr 2013 01:53:07 -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 15959 invoked from network); 5 Apr 2013 01:53:07 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3046 Archived-At: 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. The current behavior in musl is to treat EILSEQ and IO errors from the underlying stdio layer as input failures, but in light of the above, this seems wrong/non-conforming. It looks to me like, even if a number of conversions have already taken place successfully, scanf is required to return EOF anyway if an error is encountered later. This also makes the following text make more sense: 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. I previously thought the only way the function could return EOF was when no successful conversions had taken place, in which case there would be nothing to free. But if EOF can happen even after successful conversions, then it makes sense. (And it's also a pain to implement.) Does this all sound right? I'll probably wait until after the release to go working on it, and add 'm' at the same time, since scanf is ugly and fragile and not something I want to break pending a release. Rich