From dwc@sac.sfbay.sun.com Thu Jun 26 11:28:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QISE7Q027523 for ; Thu, 26 Jun 2008 11:28:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5QIRuhq028788; Thu, 26 Jun 2008 19:28:13 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K330053B1Z1JP00@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 12:28:13 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K33001KJ1Z0BNB0@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 12:28:12 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5QISCFb035857; Thu, 26 Jun 2008 11:28:12 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QIS93o027518; Thu, 26 Jun 2008 11:28:09 -0700 (PDT) Received: (from dwc@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5QIS9oE027514; Thu, 26 Jun 2008 11:28:09 -0700 (PDT) Date: Thu, 26 Jun 2008 11:28:09 -0700 (PDT) From: Don Cragun Subject: Fix *scanf() '%%' processing [PSARC/2008/407 Self Review] To: PSARC-ext@sun.com Cc: robbin.kawabata@sun.com Message-id: <200806261828.m5QIS9oE027514@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3625 I am filing this case for Robbin Kawabata. The case notes a change in behavior when using the *scanf() functions to match a percent character. I am filing this case only to note the behavior change. Since the change makes *scanf() conform to C, POSIX, SUS, SVID3, and XPG standards as well as to all Solaris 1.x and 2.x man pages (verified back to SunOS Release 4.1 man pages) and is unlikely to adversely affect any programs; I am marking this case closed approved automatic. Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Fix *scanf() '%%' processing 1.2. Name of Document Author/Supplier: Author: Robbin Kawabata 1.3 Date of This Document: 26 June, 2008 4. Technical Description Since this corrects a standards violation, this fix will probably need to be backported. Therefore, a patch release binding is requested. This case notes a behavior change for the *scanf() and *wscanf() family of functions for handling the format specification "%%", which scans a single '%' character in input. The current Solaris Nevada scanf() behavior produces a VSX test suite failure as described in CR 6690298. The current Solaris scanf() format specifier "%%", accepts a single '%' character in input, without skipping over leading whitespace. The VSX test expects the "%%" specifier to accept a '%' character whether or not it is preceded by whitespace. The existing standards require that a "%%" conversion specification should allow whitespace to precede '%' input. The XPG6 scanf() man page says: "... A conversion specification shall be executed in the following steps. Input white-space characters (as specified by the isspace function) shall be skipped, unless the conversion specification includes a [, c, C, or n conversion specifier. ... The following conversion specifers are valid: ... % Matches a single '%' character; no conversion or assignment occurs. The complete conversion specification shall be %%." Our current man page describes the same behavior (using the English "are" and "must be" instead of the Standardese "shall be"). Note the historical System V and BSD scanf() behavior with specifier "%%", did not accept whitespace before an input '%'. This is a case where the SVID3 specification did not match the UNIX System V behavior. However, Linux scanf() does accept whitespace before '%'. Because Linux systems behave according to the standards, we feel we will not be able to change the standards to match Solaris behavior. We propose to change the Solaris scanf() and wscanf() behavior so that "%%" format specifier accepts '%' input character after skipping over any whitespace characters that may precede it. We also propose adding a new note to the Solaris scanf.3c and fswscanf.3c man pages to mention the behavior change, as below: NOTES: The behavior of all of the functions described on this man page, with conversion specifier "%%", has been changed to match the description on the man pages and in various standards. Previously the "%%" specifier accepted a '%' character from input only if there were no preceding whitespace characters. The new behavior accepts '%' even if there are preceding whitespace characters. If the old behavior is desired, the conversion specification "%*[%]" can be used. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open