From darrenm@sac.sfbay.sun.com Wed Jun 25 07:12:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PECGF3025885 for ; Wed, 25 Jun 2008 07:12:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PEBahZ028703; Wed, 25 Jun 2008 22:12:15 +0800 (SGT) 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 <0K3000H26VG9PB00@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 08:12:09 -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 <0K3000B7VVG9V660@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 08:12:09 -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 m5PEC90n030927; Wed, 25 Jun 2008 07:12:09 -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 m5PEC6mN025870; Wed, 25 Jun 2008 07:12:06 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5PEC6Xe025866; Wed, 25 Jun 2008 07:12:06 -0700 (PDT) Date: Wed, 25 Jun 2008 07:12:06 -0700 (PDT) From: Darren J Moffat Subject: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] To: PSARC-ext@sun.com Message-id: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3849 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: libc printf behaviour for NULL string 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 25 June, 2008 4. Technical Description Background ---------- The current behavior of the printf(3C) family of functions in libc when passed a NULL value for a string format is undefined and usually results in a SEGV and crashed application. The workaround to applications written to depend on this behavior is to LD_PRELOAD=/usr/lib/0@0.so.1 (or the 64 bit equivalent). The workaround isn't always easy to apply (or it is too late data has been lost or corrupted by that point). Some will often state, myself included, that you shouldn't assume that the printf(3C) family will deal with a NULL argument for a string and that arguments should be checked before calling printf(3C). The behavior of the SunOS 4.x printf(3C) and that of the still shipping binary compatibility library /usr/4lib/libc.so.1 was to use the string "(null)" if the argument for a %s was NULL. This is also the behavior in current versions of GNU libc (as used on most (maybe all) mainstream Linux kernel based distributions) and the libc for FreeBSD, NetBSD, OpenBSD. The behavior of HP-UX and AIX is unknown to the author of this case, and since they are closed source there is no easy we to determine what their implementation does. It is reasonably common to find FOSS applications that when run on Solaris/OpenSolaris fail due to the behavior of the printf(3C) in libc. The GNOME libraries in snv_92 even appear to make this assumption in some places (g_log function) based on cores I've seen for gnome-settings-daemon and pidgin, I know that the Sun GNOME team has fixed such issues in the past. In both of those cases it wasn't the application that caused it but an assumption in some library code they both use for error handling. In some FOSS communities the upstream authors are often not interested in changing their source and view the failure as a Solaris bug (taking the stance that Linux and *BSD don't have this issue). Some are more accommodating and have taken a half way step and have their code check that 0@0.so.1 is LD_PRELOAD'd when running on Solaris, sometimes the authors will fix the code. This isn't a scalable way to approach the problem and hurts the reputation of Solaris and OpenSolaris releases. It also hinders the building of binaries for upstream FOSS components targeting an OpenSolaris release repository. There is a large volume of software not originally authored on Solaris/OpenSolaris that is critical to the success of OpenSolaris. So a permanent fix for this is needed that scales well in OpenSolaris and upstream community developer time. Proposal -------- This case proposes to change the default Solaris/OpenSolaris libc behavior for the printf(3C) family so that it reverts to the SunOS 4.x behavior of printing "(null)" instead of (likely) causing an application crash. This change will apply the XPG and wide char variants as well. There are no documentation changes from this case, as the current Solaris documentation says nothing about the behavior of printf(3C) family when passed a NULL. Since no application should be depending on the current behavior of getting a SEGV when a passing a NULL there is no need to making this change configurable. In fact doing so could cause even more harm than the current situation. There are no interface taxonomy changes. The release binding for this change is patch. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Wed Jun 25 07:33:42 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PEXgcJ025966 for ; Wed, 25 Jun 2008 07:33:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PEXfes004113 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Wed, 25 Jun 2008 07:33:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3000L1HWG6RP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 07:33:42 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000HF9WG5HY80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 07:33:41 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PEXeEm007550; Wed, 25 Jun 2008 10:33:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PEXdHA007547; Wed, 25 Jun 2008 10:33:39 -0400 (EDT) Date: Wed, 25 Jun 2008 10:33:39 -0400 From: James Carlson Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <18530.22339.958793.184491@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> Status: RO Content-Length: 1343 Darren J Moffat writes: > The behavior of HP-UX and AIX is unknown to the author of this case, > and since they are closed source there is no easy we to determine what > their implementation does. AIX prints an empty string, as though "" had been passed in. Our HP-UX box has locked up, or I'd give you that one as well. :-/ > This isn't a scalable way to approach the problem and hurts the > reputation of Solaris and OpenSolaris releases. It also hinders the The sad thing here is that it's really the bug-ridden application code that mishandles NULL pointers that's of poor quality, so it's not OpenSolaris's reputation that should be at stake. So, with this one under our belts, should we also fix up the str*(3C) family of functions so that they quietly ignore NULL pointers as well? An application that's incautious with NULL can't possibly just make that mistake with printf alone, can it? Is NULL the only bad pointer worth caring about? What sorts of bad pointer checks need to be made so that malfunctioning applications can continue running without dropping core? How deep does the rabbit hole go? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@sun.com Wed Jun 25 07:39:29 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 m5PEdSnD026043 for ; Wed, 25 Jun 2008 07:39:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PEdG0H008913 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 15:39:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3000L1NWPRYL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 07:39:27 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000HD4WPQI090@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 07:39:26 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PEdQMw010150 for ; Wed, 25 Jun 2008 07:39:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000801WNBQT00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 07:39:26 -0700 (PDT) Received: from [129.153.2.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K30008IGWPPTL90@fe-sfbay-10.sun.com>; Wed, 25 Jun 2008 07:39:26 -0700 (PDT) Date: Wed, 25 Jun 2008 07:39:25 -0700 From: "Garrett D'Amore" Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4862589D.60109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 4523 My only possible objection to this is that this change might mask certain kinds of bugs which might be useful to catch. Can we have an environment variable to turn off this behavior for debugging purposes (perhaps leaving it turned off by default in a debug build of ON?) A perhaps better solution might be to place an assert() in printf for the string not being NULL. (Hmmm... do we even *have* debug/non-debug versions of libc as we do for the kernel?) -- Garrett Darren J Moffat wrote: > 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: > libc printf behaviour for NULL string > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 25 June, 2008 > 4. Technical Description > > Background > ---------- > The current behavior of the printf(3C) family of functions in libc when > passed a NULL value for a string format is undefined and usually > results in a SEGV and crashed application. > > The workaround to applications written to depend on this behavior is to > LD_PRELOAD=/usr/lib/0@0.so.1 (or the 64 bit equivalent). The > workaround isn't always easy to apply (or it is too late data has been > lost or corrupted by that point). > > Some will often state, myself included, that you shouldn't assume that > the printf(3C) family will deal with a NULL argument for a string and > that arguments should be checked before calling printf(3C). > > The behavior of the SunOS 4.x printf(3C) and that of the still shipping > binary compatibility library /usr/4lib/libc.so.1 was to use the string > "(null)" if the argument for a %s was NULL. > > This is also the behavior in current versions of GNU libc (as used > on most (maybe all) mainstream Linux kernel based distributions) > and the libc for FreeBSD, NetBSD, OpenBSD. > > The behavior of HP-UX and AIX is unknown to the author of this case, > and since they are closed source there is no easy we to determine what > their implementation does. > > It is reasonably common to find FOSS applications that when run on > Solaris/OpenSolaris fail due to the behavior of the printf(3C) in > libc. The GNOME libraries in snv_92 even appear to make this > assumption in some places (g_log function) based on cores I've seen for > gnome-settings-daemon and pidgin, I know that the Sun GNOME team has > fixed such issues in the past. In both of those cases it wasn't the > application that caused it but an assumption in some library code they > both use for error handling. > > In some FOSS communities the upstream authors are often not interested > in changing their source and view the failure as a Solaris bug (taking > the stance that Linux and *BSD don't have this issue). Some are more > accommodating and have taken a half way step and have their code check > that 0@0.so.1 is LD_PRELOAD'd when running on Solaris, sometimes the > authors will fix the code. > > This isn't a scalable way to approach the problem and hurts the > reputation of Solaris and OpenSolaris releases. It also hinders the > building of binaries for upstream FOSS components targeting an > OpenSolaris release repository. There is a large volume of software > not originally authored on Solaris/OpenSolaris that is critical to the > success of OpenSolaris. So a permanent fix for this is needed that > scales well in OpenSolaris and upstream community developer time. > > > Proposal > -------- > > This case proposes to change the default Solaris/OpenSolaris libc > behavior for the printf(3C) family so that it reverts to the SunOS 4.x > behavior of printing "(null)" instead of (likely) causing an > application crash. This change will apply the XPG and wide char > variants as well. > > There are no documentation changes from this case, as the current > Solaris documentation says nothing about the behavior of printf(3C) > family when passed a NULL. > > Since no application should be depending on the current behavior of > getting a SEGV when a passing a NULL there is no need to making this > change configurable. In fact doing so could cause even more harm than > the current situation. > > There are no interface taxonomy changes. > > The release binding for this change is patch. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From binarycrusader@gmail.com Wed Jun 25 07:43:02 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PEh2nA026330 for ; Wed, 25 Jun 2008 07:43:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PEh2OW008850 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 08:43:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3000M0TWVO2S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 07:43:00 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000HNSWVNI090@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 07:43:00 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PETmPN012500 for ; Wed, 25 Jun 2008 14:42:59 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-380990 for PSARC-ext@sun.com; Wed, 25 Jun 2008 14:42:59 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-456115 for PSARC-ext@sun.com; Wed, 25 Jun 2008 14:42:59 +0000 (Z) Received: from yx-out-1718.google.com ([74.125.44.156] [74.125.44.156]) by relay1i.sun.com with ESMTP id BT-MMP-16043015 for PSARC-ext@sun.com; Wed, 25 Jun 2008 14:42:59 +0000 (Z) Received: by yx-out-1718.google.com with SMTP id 6so624836yxn.68 for ; Wed, 25 Jun 2008 07:42:55 -0700 (PDT) Received: by 10.114.184.7 with SMTP id h7mr5827656waf.9.1214404974588; Wed, 25 Jun 2008 07:42:54 -0700 (PDT) Received: by 10.114.130.6 with HTTP; Wed, 25 Jun 2008 07:42:54 -0700 (PDT) Date: Wed, 25 Jun 2008 09:42:54 -0500 From: Shawn Walker Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> Sender: binarycrusader@gmail.com To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Ta8oY1Twxck/PGBHgTmsmXUJonDyxvLbOIaiR7jtjsY=; b=AFZ4/TG6iK1i6Rm1hI4K59lx8cAGfxKoS9xZyEtWh6f/177Dz1feEobmH6fQo5e3qu zaiBRlrcCSSdfxCDGWU7+uJRHOOgJrNkYcA5DndWJg9CoHyQOHulE0uqwRtlq1mGmpxy vy963rXJ/80Q/uUuRlHOY2kXsxfK4oiTz41Jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=m9WGYbXMzKEqkv5m927rI4H4vSYE7o3ZNuJyvkjY6n5oxa8G8O7AKHwD/tO4mJEL5x vkWTgm6vyiHUVSh4nnaHdeRBzJB67zSs7v+MkcKIEvjzPfipuMRKZ8ZTvEGyBDaeHIyK cZizuocBLk3k5PQPSCd2JrQ6r5odB5CKGwp70= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 6e8ce8ca722ddd84 X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> Status: RO Content-Length: 547 2008/6/25 James Carlson : > Darren J Moffat writes: >> The behavior of HP-UX and AIX is unknown to the author of this case, >> and since they are closed source there is no easy we to determine what >> their implementation does. > > AIX prints an empty string, as though "" had been passed in. Our > HP-UX box has locked up, or I'd give you that one as well. :-/ According to Sun's developer pages [1], HP-UX has the same behaviour. -- Shawn Walker [1] http://developers.sun.com/solaris/articles/portingUNIXapps.html From Gordon.Ross@sun.com Wed Jun 25 07:51:22 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PEpMur026520 for ; Wed, 25 Jun 2008 07:51:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PEpJKR011466 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 08:51:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K300090ZX9J3Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 07:51:19 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K30008KTX9ISC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 07:51:18 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PEpI7Y002656 for ; Wed, 25 Jun 2008 14:51:18 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000C01UHQNC00@mail-amer.sun.com> (original mail from Gordon.Ross@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 08:51:18 -0600 (MDT) Received: from [129.148.168.158] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000C37X9G5J60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 08:51:17 -0600 (MDT) Date: Wed, 25 Jun 2008 10:51:14 -0400 From: Gordon Ross Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> Sender: Gordon.Ross@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <1214405474.1029.18.camel@acer-gwr> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> Status: RO Content-Length: 1626 Having ported a bunch of code with str==NULL problems, my observation is that the most common situation is the assumption that: str=NULL is treated as str="" Not only in printf (and friends: vprintf...) but also in the str* functions. The team I was working with at the time didn't want to just link 0@0 with the application because we wanted to find out about other uses of bad pointers. So instead, the approach we used was to provide wrappers that allow str=NULL to be treated as str="". It's not hard to do for the str* functions, but is rather tricky for printf because you have to walk the format string in the wrapper. One suggestion I have here would be to provide some sort of "shim" library that these (arguably broken) applications can link with that does the null string ptr substitutions. Maybe the printf internals (doprnt?) could call some function for %s that the "shim" can substitute? Gordon James Carlson wrote: > The sad thing here is that it's really the bug-ridden application > code > that mishandles NULL pointers that's of poor quality, so it's not > OpenSolaris's reputation that should be at stake. > > So, with this one under our belts, should we also fix up the str*(3C) > family of functions so that they quietly ignore NULL pointers as well? > An application that's incautious with NULL can't possibly just make > that mistake with printf alone, can it? > > Is NULL the only bad pointer worth caring about? What sorts of bad > pointer checks need to be made so that malfunctioning applications can > continue running without dropping core? How deep does the rabbit hole > go? > From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 25 07:52:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PEq9PN026553 for ; Wed, 25 Jun 2008 07:52:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PEq7Fg011938; Wed, 25 Jun 2008 08:52:08 -0600 (MDT) 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 <0K3000K0PXAWKT00@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 08:52:08 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000B1TXAVV580@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 08:52:07 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PEq6HV015275; Wed, 25 Jun 2008 14:52:06 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-950793; Wed, 25 Jun 2008 14:52:06 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-50316894; Wed, 25 Jun 2008 14:52:06 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-2232601; Wed, 25 Jun 2008 14:52:05 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw25] (8.14.2+/8.14.2) with ESMTP id m5PEq43e023564; Wed, 25 Jun 2008 16:52:04 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5PEq4b2023558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jun 2008 16:52:04 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5PEq3wY003818; Wed, 25 Jun 2008 16:52:03 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 16:52:03 +0200 Date: Wed, 25 Jun 2008 16:52:03 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> To: james.d.carlson@sun.com, darrenm@sac.sfbay.sun.com Cc: PSARC-ext@sun.com Message-id: <48625b93.NFEwGjzo4ZKehK7o%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 25 Jun 2008 14:52:03.0215 (UTC) FILETIME=[077D39F0:01C8D6D3] Status: RO Content-Length: 732 James Carlson wrote: > Darren J Moffat writes: > > The behavior of HP-UX and AIX is unknown to the author of this case, > > and since they are closed source there is no easy we to determine what > > their implementation does. > > AIX prints an empty string, as though "" had been passed in. Our > HP-UX box has locked up, or I'd give you that one as well. :-/ HP-UX also prints an empty string like: "" Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Wed Jun 25 08:16:21 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFGLdk027505 for ; Wed, 25 Jun 2008 08:16:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFGL4K023745 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 08:16:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3000011YF85J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 08:16:20 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000HM5YF2HUC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 08:16:15 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFGE70013729 for ; Wed, 25 Jun 2008 15:16:14 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000H01W5MMX00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 16:16:14 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000MB2YEMAG30@fe-emea-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 16:16:01 +0100 (BST) Date: Wed, 25 Jun 2008 16:15:58 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862589D.60109@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <4862612E.3070006@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <4862589D.60109@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1473 Garrett D'Amore wrote: > My only possible objection to this is that this change might mask > certain kinds of bugs which might be useful to catch. Doesn't seem to be a problem for other platforms. > Can we have an environment variable to turn off this behavior for > debugging purposes (perhaps leaving it turned off by default in a debug > build of ON?) I don't think that is a good idea. None of the other platforms I viewed have this and we didn't have this with SunOS 4.x either. More importantly I don't like the idea of having to check an environment variable on every printf(3C) family call, there could be a noticable performance hit for that. Basically I see the current behaviour as a long standing regression from SunOS 4.x and was really tempted to not even file an ARC case but just do a bug fix. Lets not over design this or beat it to death in ARC unless there is a standards reason our sound architectural reason why this is the wrong thing do to (and given the behaviour of all the other platforms I'd have a hard time believing that). > A perhaps better solution might be to place an assert() > in printf for the string not being NULL. (Hmmm... do we even *have* > debug/non-debug versions of libc as we do for the kernel?) No we don't, but then with DTrace we don't need to either. If the goal is to find applications that could be fixed to not do this then use DTrace with the pid provider to find them. -- Darren J Moffat From Darren.Moffat@Sun.COM Wed Jun 25 08:23:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFNR7b027743 for ; Wed, 25 Jun 2008 08:23:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFNRUp025152 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 09:23:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K300000BYR2CS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 08:23:26 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000HE3YR0HYC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 08:23:24 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFNNYE001274 for ; Wed, 25 Jun 2008 15:23:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000H01W5MMX00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 16:23:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000MQCYQUAG30@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 16:23:20 +0100 (BST) Date: Wed, 25 Jun 2008 16:23:18 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <1214405474.1029.18.camel@acer-gwr> Sender: Darren.Moffat@Sun.COM To: Gordon Ross Cc: James Carlson , PSARC-ext@Sun.COM Message-id: <486262E6.1050401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <1214405474.1029.18.camel@acer-gwr> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1566 Gordon Ross wrote: > Having ported a bunch of code with str==NULL problems, > my observation is that the most common situation is the > assumption that: > str=NULL is treated as str="" > Not only in printf (and friends: vprintf...) > but also in the str* functions. > > The team I was working with at the time didn't want to > just link 0@0 with the application because we wanted to > find out about other uses of bad pointers. So instead, > the approach we used was to provide wrappers that allow > str=NULL to be treated as str="". It's not hard to do > for the str* functions, but is rather tricky for printf > because you have to walk the format string in the wrapper. > > One suggestion I have here would be to provide some sort of > "shim" library that these (arguably broken) applications > can link with that does the null string ptr substitutions. > Maybe the printf internals (doprnt?) could call some > function for %s that the "shim" can substitute? I'm not interested in doing that as part of this case. None of the other platforms have this and I just don't see the point in doing that. DTrace can be used to find the cases where NULL is passed where it would currently cause a SEGV on Solaris but won't on our competitors platforms. Lets just end the madness of Solaris being different and get over the purity aspects of this. This case is about making Solaris/OpenSolaris familiar and attractive for developers and users and that means doing what all the other kids on the block do nothing more and nothing less. -- Darren J Moffat From Darren.Moffat@sun.com Wed Jun 25 08:26:27 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFQRp1027844 for ; Wed, 25 Jun 2008 08:26:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFQQ2J026999 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 08:26:26 -0700 (PDT) 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 <0K3000M07YW2SR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 09:26:26 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000BTUYW1V6B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 09:26:25 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFQPSm001631 for ; Wed, 25 Jun 2008 15:26:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000L01XRXAO00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 16:26:25 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000MWNYVLAG30@fe-emea-10.sun.com>; Wed, 25 Jun 2008 16:26:10 +0100 (BST) Date: Wed, 25 Jun 2008 16:26:09 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: Shawn Walker Cc: James Carlson , Darren J Moffat , PSARC-ext@sun.com Message-id: <48626391.6050401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 753 Shawn Walker wrote: > 2008/6/25 James Carlson : >> Darren J Moffat writes: >>> The behavior of HP-UX and AIX is unknown to the author of this case, >>> and since they are closed source there is no easy we to determine what >>> their implementation does. >> AIX prints an empty string, as though "" had been passed in. Our >> HP-UX box has locked up, or I'd give you that one as well. :-/ > > According to Sun's developer pages [1], HP-UX has the same behaviour. and that page even says: "Because these practices occur so often, identifying and fixing all occurrences can be impractical." Which is why I'm filing this case. Fix the issue in the one place that causes all the pain: the Solaris libc. -- Darren J Moffat From kmcdonald@egenera.com Wed Jun 25 08:32:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFWJVJ028114 for ; Wed, 25 Jun 2008 08:32:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFWIRV029083; Wed, 25 Jun 2008 08:32:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3000C55Z5QST00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 08:32:14 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K30008OYZ5OSG70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 08:32:12 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFLIqH028909; Wed, 25 Jun 2008 15:32:12 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-379817; Wed, 25 Jun 2008 15:32:12 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-52628; Wed, 25 Jun 2008 15:32:11 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay1ib.sun.com with ESMTP id BT-MMP-15132554; Wed, 25 Jun 2008 15:32:11 +0000 (Z) Received: from [172.23.2.142] ([172.23.2.142]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:33:36 -0400 Date: Wed, 25 Jun 2008 11:33:33 -0400 From: Kyle McDonald Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4862654D.3050801@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.059sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-OriginalArrivalTime: 25 Jun 2008 15:33:36.0221 (UTC) FILETIME=[D56FC0D0:01C8D6D8] Status: RO Content-Length: 1594 James Carlson wrote: > Darren J Moffat writes: > >> The behavior of HP-UX and AIX is unknown to the author of this case, >> and since they are closed source there is no easy we to determine what >> their implementation does. >> > > AIX prints an empty string, as though "" had been passed in. Our > HP-UX box has locked up, or I'd give you that one as well. :-/ > > If memory serves, I seem to remember at least one platform (can't recall which) where passing a NULL pointer as a string to printf actually caused printf to print the string "". I don't remember which platform that was, though, Scince it's not AIX or (from another post) HP-UX, then the only other ones I worked on were IRIX and Ultrix...oh and a little OSF/1. -Kyle >> This isn't a scalable way to approach the problem and hurts the >> reputation of Solaris and OpenSolaris releases. It also hinders the >> > > The sad thing here is that it's really the bug-ridden application code > that mishandles NULL pointers that's of poor quality, so it's not > OpenSolaris's reputation that should be at stake. > > So, with this one under our belts, should we also fix up the str*(3C) > family of functions so that they quietly ignore NULL pointers as well? > An application that's incautious with NULL can't possibly just make > that mistake with printf alone, can it? > > Is NULL the only bad pointer worth caring about? What sorts of bad > pointer checks need to be made so that malfunctioning applications can > continue running without dropping core? How deep does the rabbit hole > go? > > From piochjennifer@googlemail.com Wed Jun 25 08:32:25 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFWPH8028132 for ; Wed, 25 Jun 2008 08:32:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFWN2Q028840 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 09:32:24 -0600 (MDT) 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 <0K300000ZZ5Y1200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:32:23 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000B7SZ5UUVA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:32:18 -0600 (MDT) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PFU1pX029167 for ; Wed, 25 Jun 2008 15:32:18 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay18i.sun.com with ESMTP id BT-MMP-1183090 for PSARC-ext@sun.com; Wed, 25 Jun 2008 15:32:17 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-52793 for PSARC-ext@sun.com; Wed, 25 Jun 2008 15:32:17 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.176] [64.233.166.176]) by relay1ib.sun.com with ESMTP id BT-MMP-4198521 for PSARC-ext@sun.com; Wed, 25 Jun 2008 15:32:17 +0000 (Z) Received: by py-out-1112.google.com with SMTP id u77so1967798pyb.5 for ; Wed, 25 Jun 2008 08:32:17 -0700 (PDT) Received: by 10.141.71.14 with SMTP id y14mr16458550rvk.253.1214407936240; Wed, 25 Jun 2008 08:32:16 -0700 (PDT) Received: by 10.140.163.10 with HTTP; Wed, 25 Jun 2008 08:32:16 -0700 (PDT) Date: Wed, 25 Jun 2008 17:32:16 +0200 From: Jennifer Pioch Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> To: PSARC-ext@sun.com Message-id: <67079b830806250832r7ab123edtc47251dbdc6277fe@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sc7iPUgRvpWNWjoefs3aH6tesEqgFeMuzbbRwcHXjS0=; b=VriWnvtIBjDjHf7EoOW3NnKwL3QInV9h1UoxyeVsypdLfVavxww9B977BuDvZF2Gos eldfu/NpIQK4pOu9m0bQ1VvZnvE4VEM2DjiPtfVEGxw7Q9dFyQjrZz9HPQHtrrWPanim Iex/IGWA13q2zUe4Jg3H8sZUhEAqT/t7M83R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=b1IVDbNqBKcAsG8ZisJ/6eRw9wt3hnxltJ4SNN0qnpmxYOkWsEDDwImg6BNMt9yv2y Hj6looNt/i1HOwx4R3vWTC1pTxKzwjDvSqPv3rG42+67bvkUhnqsFpupcJfCb3rA8sOz CozX/cwC9/BNfTDO25Pjm0vEmqys3Dmm5vBV4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.082sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> Status: RO Content-Length: 1479 On 6/25/08, Darren J Moffat wrote: > > 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: > libc printf behaviour for NULL string > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 25 June, 2008 > 4. Technical Description > > Background > ---------- > The current behavior of the printf(3C) family of functions in libc when > passed a NULL value for a string format is undefined and usually > results in a SEGV and crashed application. > > The workaround to applications written to depend on this behavior is to > LD_PRELOAD=/usr/lib/0@0.so.1 (or the 64 bit equivalent). The > workaround isn't always easy to apply (or it is too late data has been > lost or corrupted by that point). > > Some will often state, myself included, that you shouldn't assume that > the printf(3C) family will deal with a NULL argument for a string and > that arguments should be checked before calling printf(3C). > > The behavior of the SunOS 4.x printf(3C) and that of the still shipping > binary compatibility library /usr/4lib/libc.so.1 was to use the string > "(null)" if the argument for a %s was NULL. The string "(null)" needs to be localised like in Linux, i.e. LC_ALL=de_AT.utf8 must print "(nichts)". Jenny -- Jennifer Pioch, Uni Frankfurt From Darren.Moffat@sun.com Wed Jun 25 08:35:23 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFZN6o028781 for ; Wed, 25 Jun 2008 08:35:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFZ7ZQ026005 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 08:35:23 -0700 (PDT) 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 <0K300000LZAXAD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 09:35:21 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000BKQZAVUVA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 09:35:20 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFZJ92002762 for ; Wed, 25 Jun 2008 15:35:19 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000L01XRXAO00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 16:35:19 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000MF5ZALAG40@fe-emea-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 16:35:11 +0100 (BST) Date: Wed, 25 Jun 2008 16:35:09 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <486265AD.9040103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 2053 James Carlson wrote: > Darren J Moffat writes: >> The behavior of HP-UX and AIX is unknown to the author of this case, >> and since they are closed source there is no easy we to determine what >> their implementation does. > > AIX prints an empty string, as though "" had been passed in. Our > HP-UX box has locked up, or I'd give you that one as well. :-/ > >> This isn't a scalable way to approach the problem and hurts the >> reputation of Solaris and OpenSolaris releases. It also hinders the > > The sad thing here is that it's really the bug-ridden application code > that mishandles NULL pointers that's of poor quality, so it's not > OpenSolaris's reputation that should be at stake. Oh I agree completely but we are the odd one out here. > So, with this one under our belts, should we also fix up the str*(3C) > family of functions so that they quietly ignore NULL pointers as well? The goal of this case was parity with the other mentioned libc implementations. I have looked at what the others do for strlen(NULL) and they will SEGV on that. I haven't looked at every str*(3C) function. > An application that's incautious with NULL can't possibly just make > that mistake with printf alone, can it? Probably not but this is a "safety net" that is available on other platforms. Similar saftey nets for the str*(3C) functions don't at initial glance appear to exist. If the applicaiton/lib is that free and loose with NULL then we still have the ability to LD_PRELOAD=0@0.so.1 if the code can't be fixed. This case is about fixing the very commonly encountered case and the case were Solaris is disastrously different to the common platforms. > Is NULL the only bad pointer worth caring about? What sorts of bad > pointer checks need to be made so that malfunctioning applications can > continue running without dropping core? How deep does the rabbit hole > go? The Rabbit hole is very deep but this case is just about getting dinner for tonight, someone else can explore the rest of the warren. -- Darren J Moffat From Darren.Moffat@sun.com Wed Jun 25 08:38:37 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 m5PFcaFM028861 for ; Wed, 25 Jun 2008 08:38:37 -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 m5PFcTWu007285 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 16:38:36 +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 <0K300001JZG9FD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:38:33 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3000BJTZG9V8B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:38:33 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PFcWVC016836 for ; Wed, 25 Jun 2008 15:38:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3000H01W5MMX00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 16:38:32 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3000MM2ZFUAG40@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 16:38:19 +0100 (BST) Date: Wed, 25 Jun 2008 16:38:18 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <67079b830806250832r7ab123edtc47251dbdc6277fe@mail.gmail.com> Sender: Darren.Moffat@sun.com To: Jennifer Pioch Cc: PSARC-ext@sun.com Message-id: <4862666A.7060902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <67079b830806250832r7ab123edtc47251dbdc6277fe@mail.gmail.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 488 Jennifer Pioch wrote: >> The behavior of the SunOS 4.x printf(3C) and that of the still shipping >> binary compatibility library /usr/4lib/libc.so.1 was to use the string >> "(null)" if the argument for a %s was NULL. > > The string "(null)" needs to be localised like in Linux, i.e. > LC_ALL=de_AT.utf8 must print "(nichts)". Why does it need to be ? What breaks if it isn't ? I'm not saying I won't consider that but I don't really see why it must be done. -- Darren J Moffat From don.cragun@sun.com Wed Jun 25 08:53:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFrwcY029228 for ; Wed, 25 Jun 2008 08:53:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PFrwwH008431 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 25 Jun 2008 08:53:58 -0700 (PDT) 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 <0K310011705WHG00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 09:53:56 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100B0D05VUVC0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 09:53:55 -0600 (MDT) Received: from spartan.eng.sun.com (spartan.SFBay.Sun.COM [129.146.226.64]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PFrs8w019426; Wed, 25 Jun 2008 08:53:54 -0700 (PDT) Received: from spartan (spartan [129.146.226.64]) by spartan.eng.sun.com (8.13.7+Sun/8.13.7) with SMTP id m5PFkO6E012604; Wed, 25 Jun 2008 08:46:24 -0700 (PDT) Date: Wed, 25 Jun 2008 08:46:24 -0700 (PDT) From: Don Cragun Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] To: Darren.Moffat@sun.com Cc: PSARC-ext@sun.com Reply-to: Don Cragun Message-id: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6.2 SunOS 5.10 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Up7uDR6TZkvqTs/N3IAgWg== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1339 >Date: Wed, 25 Jun 2008 16:15:58 +0100 >From: Darren J Moffat ... ... ... > >Basically I see the current behaviour as a long standing regression from >SunOS 4.x and was really tempted to not even file an ARC case but just >do a bug fix. Lets not over design this or beat it to death in ARC >unless there is a standards reason our sound architectural reason why >this is the wrong thing do to (and given the behaviour of all the other >platforms I'd have a hard time believing that). There is no standards reason for changing the behavior or leaving it as is. The standards all say that passing a null pointer to a *printf() function for a format specifier that expects a pointer to a string produces undefined results. I don't know whether you consider it to be a sound architectural reason or not, but there was a conscious design decision made when Sun negotiated SunOS 5.0 behavior with AT&T not to check for bad code that used NULL as a pointer to a string. When libc converts NULL to "", to "(null)", or some other arbitrary string instead of dropping core when trying to dereference the bad pointer, it slows down all applications that use correct pointers, it delays debugging efforts, and it makes it more likely that a bad pointer will cause something downstream to corrupt other data. - Don From Stefan.Teleman@Sun.COM Wed Jun 25 08:54:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PFs7Ln029424 for ; Wed, 25 Jun 2008 08:54:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PFs2sn007889; Wed, 25 Jun 2008 23:54:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100103060AA00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 08:54:00 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K310010805ZA100@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 08:54:00 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PFrxND416118; Wed, 25 Jun 2008 08:53:59 -0700 (PDT) Date: Wed, 25 Jun 2008 11:53:59 -0400 From: Stefan Teleman Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486265AD.9040103@Sun.COM> To: Darren J Moffat Cc: James Carlson , PSARC-ext@Sun.COM Reply-to: Stefan Teleman Message-id: <48626A17.40707@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 697 Darren J Moffat wrote: >> The sad thing here is that it's really the bug-ridden application code >> that mishandles NULL pointers that's of poor quality, so it's not >> OpenSolaris's reputation that should be at stake. > > Oh I agree completely but we are the odd one out here. I apologize for interjecting in this discussion, but, wouldn't the character string "(null)" or "(nichts)" or "" being printed on stdout/stderr act as a clear indicator of the bug, and of its precise location ? Wouldn't it be nice to be able to figure out where the NULL pointer is, without having to load a core file in dbx ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From carlsonj@phorcys.east.sun.com Wed Jun 25 09:02:01 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 m5PG20Er000137 for ; Wed, 25 Jun 2008 09:02:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PG1w2o017097; Wed, 25 Jun 2008 17:01:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310010J0JBKD00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:01:59 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001R60JA9Y00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:01:58 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PG1vsd008145; Wed, 25 Jun 2008 12:01:57 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PG1viH008142; Wed, 25 Jun 2008 12:01:57 -0400 (EDT) Date: Wed, 25 Jun 2008 12:01:57 -0400 From: James Carlson Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486265AD.9040103@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <18530.27637.798196.214228@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> Status: RO Content-Length: 1128 Darren J Moffat writes: > James Carlson wrote: > > So, with this one under our belts, should we also fix up the str*(3C) > > family of functions so that they quietly ignore NULL pointers as well? > > The goal of this case was parity with the other mentioned libc > implementations. I have looked at what the others do for strlen(NULL) > and they will SEGV on that. I haven't looked at every str*(3C) function. OK. That's what I was looking for. I did some searching, too, and couldn't find str*(3C) functions that ignored NULL, but wasn't sure. I wanted to know that hacking printf in this way was "complete" for the applications that apparently need it. > If the applicaiton/lib is that free and loose with NULL then we still > have the ability to LD_PRELOAD=0@0.so.1 if the code can't be fixed. Sure, but that gets us right back to the original problem, which is that they don't wanna. ;-} -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Wed Jun 25 09:03:36 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PG3ZGF000401 for ; Wed, 25 Jun 2008 09:03:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PG3YTM041439; Wed, 25 Jun 2008 10:03:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310012D0LXLH00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:03:33 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001UR0LWA100@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:03:32 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PG3VIl020022; Wed, 25 Jun 2008 16:03:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K31008010HIR100@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 25 Jun 2008 17:03:31 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3100M010LRAG60@fe-emea-10.sun.com>; Wed, 25 Jun 2008 17:03:29 +0100 (BST) Date: Wed, 25 Jun 2008 17:03:27 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> Sender: Darren.Moffat@sun.com To: Don Cragun Cc: PSARC-ext@sun.com Message-id: <48626C4F.5080705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1894 Don Cragun wrote: >> Date: Wed, 25 Jun 2008 16:15:58 +0100 >> From: Darren J Moffat > ... ... ... >> Basically I see the current behaviour as a long standing regression from >> SunOS 4.x and was really tempted to not even file an ARC case but just >> do a bug fix. Lets not over design this or beat it to death in ARC >> unless there is a standards reason our sound architectural reason why >> this is the wrong thing do to (and given the behaviour of all the other >> platforms I'd have a hard time believing that). > > There is no standards reason for changing the behavior or leaving it as > is. The standards all say that passing a null pointer to a *printf() > function for a format specifier that expects a pointer to a string > produces undefined results. Thanks for that. > I don't know whether you consider it to be a sound architectural reason > or not, but there was a conscious design decision made when Sun > negotiated SunOS 5.0 behavior with AT&T not to check for bad code that > used NULL as a pointer to a string. When libc converts NULL to "", to > "(null)", or some other arbitrary string instead of dropping core when > trying to dereference the bad pointer, it slows down all applications > that use correct pointers, it delays debugging efforts, and it makes it > more likely that a bad pointer will cause something downstream to > corrupt other data. IMO that was the wrong decision given that the additional code in SunOS 4.x was basically this: static char nullstr = "(null)"; ... if (bp == NULL) bp = nullstr; Even a more advanced check that does localisation calls wouldn't impact "correct" applications because it is just one 'if (bp == NULL)' and looking that the implementation of printf that isn't going to impact its performance it has much bigger issues (that are not part of this case!). -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Jun 25 09:14:36 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PGEaUF001366 for ; Wed, 25 Jun 2008 09:14:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PGEYQ2009686; Wed, 25 Jun 2008 09:14:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310010914AXW00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:14:34 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001T21489R10@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:14:33 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PGEWW3008234; Wed, 25 Jun 2008 12:14:32 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PGEWq8008231; Wed, 25 Jun 2008 12:14:32 -0400 (EDT) Date: Wed, 25 Jun 2008 12:14:32 -0400 From: James Carlson Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <48626A17.40707@Sun.COM> To: Stefan Teleman Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <18530.28392.679252.318186@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> <48626A17.40707@Sun.COM> Status: RO Content-Length: 1697 Stefan Teleman writes: > > > Darren J Moffat wrote: > > >> The sad thing here is that it's really the bug-ridden application code > >> that mishandles NULL pointers that's of poor quality, so it's not > >> OpenSolaris's reputation that should be at stake. > > > > Oh I agree completely but we are the odd one out here. > > I apologize for interjecting in this discussion, but, wouldn't the character > string "(null)" or "(nichts)" or "" being printed on stdout/stderr act as > a clear indicator of the bug, and of its precise location ? Actually, no, it's not. You know its apparent location in the stdout character stream, but nothing about where the problem might be in the code. And what's worse, if that error occurs during a script that invokes multiple utilities, then you've got almost zero information. You'll probably have to resort to running 'strings' on the binaries to locate the apparent culprit, and still not be close to finding the problem. A core dump, on the other hand, gives you precise information about the location of the problem and which process suffered it. I much prefer to have precise information about my bugs rather than log messages, particularly ones delivered to a user who can do nothing about them. For an extreme version of how far it can go, start up 'evince' in a terminal window. My favorite random error message is "some font thing failed" -- but it also spews a large number of warnings about NULL pointers. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@sun.com Wed Jun 25 09:20:26 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PGKQeV001575 for ; Wed, 25 Jun 2008 09:20:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PGKPpf011816; Wed, 25 Jun 2008 09:20:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100H131E1SB00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 09:20:25 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100GTH1E1J400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 09:20:25 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PGKPns029636; Wed, 25 Jun 2008 09:20:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3100A010WYX800@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Wed, 25 Jun 2008 09:20:25 -0700 (PDT) Received: from [129.153.2.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31003221DZXN30@fe-sfbay-09.sun.com>; Wed, 25 Jun 2008 09:20:25 -0700 (PDT) Date: Wed, 25 Jun 2008 09:20:23 -0700 From: "Garrett D'Amore" Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> Sender: Garrett.Damore@sun.com To: Don Cragun Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com Message-id: <48627047.3050100@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Cli9RoQpJyl5+EuXD4jQNA)" X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 7684 This is a multi-part message in MIME format. --Boundary_(ID_Cli9RoQpJyl5+EuXD4jQNA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Don Cragun wrote: >> Date: Wed, 25 Jun 2008 16:15:58 +0100 >> From: Darren J Moffat >> > ... ... ... > >> Basically I see the current behaviour as a long standing regression from >> SunOS 4.x and was really tempted to not even file an ARC case but just >> do a bug fix. Lets not over design this or beat it to death in ARC >> unless there is a standards reason our sound architectural reason why >> this is the wrong thing do to (and given the behaviour of all the other >> platforms I'd have a hard time believing that). >> > > There is no standards reason for changing the behavior or leaving it as > is. The standards all say that passing a null pointer to a *printf() > function for a format specifier that expects a pointer to a string > produces undefined results. > > I don't know whether you consider it to be a sound architectural reason > or not, but there was a conscious design decision made when Sun > negotiated SunOS 5.0 behavior with AT&T not to check for bad code that > used NULL as a pointer to a string. When libc converts NULL to "", to > "(null)", or some other arbitrary string instead of dropping core when > trying to dereference the bad pointer, it slows down all applications > that use correct pointers, it delays debugging efforts, and it makes it > more likely that a bad pointer will cause something downstream to > corrupt other data. > The performance and debugging questions are germane I think. I hate to think that all code in ON that ever does printf() would ever need this check. :-) Even though individually the results are small, taken collectively, they add up. (Sort of the software version of "think globally, act locally" -- I wonder what the additional power consumption is that this check would cost when aggregated globally.) Perhaps we can have a compile-time decision, such as done with XPG4 versus Sun definitions of things like strtok_r, where broken code is allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch. It would then be a matter of a man page update to allow developers to decide whether they need/want this behavior for their (broken) code. But then again, we do have 0@0.so.1, right? It *sounds* like there are two possible decisions before ARC. Either: 1) We continue to declare such behavior "buggy" (results undefined), and offer workarounds ala 0@0.so.1 or 2) We redefine the behavior such that use of NULL here is declared permissible, and we take the hypothetized hits (if any) to performance and debuggability. My leaning is to #1. It seems like we're trying to make bad applications happy, to satisfy what is probably a small minority of developers who feel that such use of NULL should be legal (despite documentation to the contrary) -- and who are unwilling to use a perfectly reasonable workaround, at a potential cost to the greater set of well-behaved applications. It may be that some feel that the options presented here are an implementation detail. But, I'm not convinced. If we feel so strongly that we need to offer this behavior *by default* (and as the submitter proposes, without any alternative to disable it), then we should be willing to stand by it in the form of a documented promise. -- Garrett --Boundary_(ID_Cli9RoQpJyl5+EuXD4jQNA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Don Cragun wrote: 
Date: Wed, 25 Jun 2008 16:15:58 +0100
From: Darren J Moffat <Darren.Moffat@sun.com>
    
 ... ... ...
  
Basically I see the current behaviour as a long standing regression from 
SunOS 4.x and was really tempted to not even file an ARC case but just 
do a bug fix.  Lets not over design this or beat it to death in ARC 
unless there is a standards reason our sound architectural reason why 
this is the wrong thing do to (and given the behaviour of all the other 
platforms I'd have a hard time believing that).
    

There is no standards reason for changing the behavior or leaving it as
is.  The standards all say that passing a null pointer to a *printf()
function for a format specifier that expects a pointer to a string
produces undefined results.

I don't know whether you consider it to be a sound architectural reason
or not, but there was a conscious design decision made when Sun
negotiated SunOS 5.0 behavior with AT&T not to check for bad code that
used NULL as a pointer to a string.  When libc converts NULL to "", to
"(null)", or some other arbitrary string instead of dropping core when
trying to dereference the bad pointer, it slows down all applications
that use correct pointers, it delays debugging efforts, and it makes it
more likely that a bad pointer will cause something downstream to
corrupt other data.

The performance and debugging questions are germane I think.  I hate to think that all code in ON that ever does printf() would ever need this check. :-)  Even though individually the results are small, taken collectively, they add up.   (Sort of the software version of "think globally, act locally" -- I wonder what the additional power consumption is that this check would cost when aggregated globally.)

Perhaps we can have a compile-time decision, such as done with XPG4 versus Sun definitions of things like strtok_r, where broken code is allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch.

It would then be a matter of a man page update to allow developers to decide whether they need/want this behavior for their (broken) code.

But then again, we do have 0@0.so.1, right?

It *sounds* like there are two possible decisions before ARC.   Either:

1) We continue to declare such behavior "buggy" (results undefined), and offer workarounds ala 0@0.so.1

or

2) We redefine the behavior such that use of NULL here is declared permissible, and we take the hypothetized hits (if any) to performance and debuggability.

My leaning is to #1.  It seems like we're trying to make bad applications happy, to satisfy what is probably a small minority of developers who feel that such use of NULL should be legal (despite documentation to the contrary) -- and who are unwilling to use a perfectly reasonable workaround, at a potential cost to the greater set of well-behaved applications.

It may be that some feel that the options presented here are an implementation detail.  But, I'm not convinced.  If we feel so strongly that we need to offer this behavior *by default* (and as the submitter proposes, without any alternative to disable it), then we should be willing to stand by it in the form of a documented promise.

    -- Garrett

--Boundary_(ID_Cli9RoQpJyl5+EuXD4jQNA)-- From Suresh.Narayana@sun.com Wed Jun 25 09:25:35 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PGPZMb001659 for ; Wed, 25 Jun 2008 09:25:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PGPYrD020035 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 09:25:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310021T1MJBK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 09:25:31 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001NB1MI9W20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 09:25:30 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PGPtDJ008131 for ; Wed, 25 Jun 2008 16:25:55 +0000 (GMT) Received: from sun.com ([129.158.123.14]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0K3100MCU1LSLRHP@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 26 Jun 2008 00:25:04 +0800 (SGT) Received: from [192.18.19.173] (Forwarded-For: [129.150.156.19]) by sedge2-mail1.singapore.sun.com (mshttpd); Wed, 25 Jun 2008 21:25:29 +0500 Date: Wed, 25 Jun 2008 21:25:29 +0500 From: Suresh Kalale Narayana Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> Status: RO Content-Length: 4610 will it affect/change sprintf/snprintf also or printf only.. its probably, good to have them in string operations also, unless we dont change the execution behaviour or dont loose the coredumps for debug. May be, it requires carefull look at what/where the changes are required. thanks, suresh ----- Original Message ----- From: Darren J Moffat Date: Wednesday, June 25, 2008 7:43 pm Subject: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] To: PSARC-ext@Sun.COM > > 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: > libc printf behaviour for NULL string > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 25 June, 2008 > 4. Technical Description > > Background > ---------- > The current behavior of the printf(3C) family of functions in libc > whenpassed a NULL value for a string format is undefined and usually > results in a SEGV and crashed application. > > The workaround to applications written to depend on this behavior > is to > LD_PRELOAD=/usr/lib/0@0.so.1 (or the 64 bit equivalent). The > workaround isn't always easy to apply (or it is too late data has been > lost or corrupted by that point). > > Some will often state, myself included, that you shouldn't assume that > the printf(3C) family will deal with a NULL argument for a string and > that arguments should be checked before calling printf(3C). > > The behavior of the SunOS 4.x printf(3C) and that of the still > shippingbinary compatibility library /usr/4lib/libc.so.1 was to use > the string > "(null)" if the argument for a %s was NULL. > > This is also the behavior in current versions of GNU libc (as used > on most (maybe all) mainstream Linux kernel based distributions) > and the libc for FreeBSD, NetBSD, OpenBSD. > > The behavior of HP-UX and AIX is unknown to the author of this case, > and since they are closed source there is no easy we to determine what > their implementation does. > > It is reasonably common to find FOSS applications that when run on > Solaris/OpenSolaris fail due to the behavior of the printf(3C) in > libc. The GNOME libraries in snv_92 even appear to make this > assumption in some places (g_log function) based on cores I've seen > forgnome-settings-daemon and pidgin, I know that the Sun GNOME team > hasfixed such issues in the past. In both of those cases it wasn't > theapplication that caused it but an assumption in some library > code they > both use for error handling. > > In some FOSS communities the upstream authors are often not interested > in changing their source and view the failure as a Solaris bug (taking > the stance that Linux and *BSD don't have this issue). Some are more > accommodating and have taken a half way step and have their code check > that 0@0.so.1 is LD_PRELOAD'd when running on Solaris, sometimes the > authors will fix the code. > > This isn't a scalable way to approach the problem and hurts the > reputation of Solaris and OpenSolaris releases. It also hinders the > building of binaries for upstream FOSS components targeting an > OpenSolaris release repository. There is a large volume of software > not originally authored on Solaris/OpenSolaris that is critical to the > success of OpenSolaris. So a permanent fix for this is needed that > scales well in OpenSolaris and upstream community developer time. > > > Proposal > -------- > > This case proposes to change the default Solaris/OpenSolaris libc > behavior for the printf(3C) family so that it reverts to the SunOS 4.x > behavior of printing "(null)" instead of (likely) causing an > application crash. This change will apply the XPG and wide char > variants as well. > > There are no documentation changes from this case, as the current > Solaris documentation says nothing about the behavior of printf(3C) > family when passed a NULL. > > Since no application should be depending on the current behavior of > getting a SEGV when a passing a NULL there is no need to making this > change configurable. In fact doing so could cause even more harm than > the current situation. > > There are no interface taxonomy changes. > > The release binding for this change is patch. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From carlsonj@phorcys.east.sun.com Wed Jun 25 09:30:27 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PGURds001943 for ; Wed, 25 Jun 2008 09:30:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PGUN8g052959; Wed, 25 Jun 2008 10:30:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310020L1UPU900@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:30:25 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001OM1UOA320@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:30:25 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PGUOmC008355; Wed, 25 Jun 2008 12:30:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PGUOSB008352; Wed, 25 Jun 2008 12:30:24 -0400 (EDT) Date: Wed, 25 Jun 2008 12:30:24 -0400 From: James Carlson Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <48627047.3050100@sun.com> To: "Garrett D'Amore" Cc: Don Cragun , PSARC-ext@sun.com Message-id: <18530.29344.707553.75030@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> Status: RO Content-Length: 1318 Garrett D'Amore writes: > My leaning is to #1. It seems like we're trying to make bad > applications happy, to satisfy what is probably a small minority of > developers who feel that such use of NULL should be legal (despite > documentation to the contrary) -- and who are unwilling to use a > perfectly reasonable workaround, at a potential cost to the greater set > of well-behaved applications. I think what's missing there is that this is (unfortunately) not just a minority of developers. The bulk of user-space software looks like this these days. People are just plain careless, and either we live with it to make those applications "just work," or we suffer random GNOME applications dropping core on OpenSolaris and nobody really caring because it's "only" OpenSolaris that has this "problem." I agree that making the system harder to debug (inserting an sdt for this case would be a nice thing to do, so that those of us who care can still trap out these cases, at least in testing) and encourages sloppy code, but this _does_ seem to fit with the Linux compatibility goal. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From edward.pilatowicz@Sun.COM Wed Jun 25 09:38:42 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 m5PGcfAK002048 for ; Wed, 25 Jun 2008 09:38:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PGcZh0004889; Wed, 25 Jun 2008 17:38:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310030F28C4500@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:38:36 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K310014228A9R30@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:38:34 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PGcY7T427856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 09:38:34 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PGcYaO427855; Wed, 25 Jun 2008 09:38:34 -0700 (PDT) Date: Wed, 25 Jun 2008 09:38:34 -0700 From: Edward Pilatowicz Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862612E.3070006@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <20080625163834.GH198017@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <4862589D.60109@sun.com> <4862612E.3070006@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1046 On Wed, Jun 25, 2008 at 04:15:58PM +0100, Darren J Moffat wrote: > Garrett D'Amore wrote: >> Can we have an environment variable to turn off this behavior for >> debugging purposes (perhaps leaving it turned off by default in a debug >> build of ON?) > > I don't think that is a good idea. None of the other platforms I viewed > have this and we didn't have this with SunOS 4.x either. More importantly > I don't like the idea of having to check an environment variable on every > printf(3C) family call, there could be a noticable performance hit for > that. > i agree with garrett here. it would be nice to have an enviroment variable to disable this functionality. currently, libc has a handfull of different env variables that control debugging behavior. all these variables are checked once during libc init (see etest()) and then cached in tls for speed. i regularly use LIBTHREAD_ERROR_DETECTION to find and file bugs. if there was an environment variable to control this behavior i would enable it by default in my environment. ed From Darren.Moffat@sun.com Wed Jun 25 09:40:08 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 m5PGe7Kc002064 for ; Wed, 25 Jun 2008 09:40:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PGe0SL005816 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 17:40:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100J032ATNV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:40:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100GRT2ARIW20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 09:40:04 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PGe3rU023727 for ; Wed, 25 Jun 2008 16:40:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K31005011UJMD00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 17:40:03 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31008J32APEY80@fe-emea-09.sun.com>; Wed, 25 Jun 2008 17:40:02 +0100 (BST) Date: Wed, 25 Jun 2008 17:40:01 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: Suresh Kalale Narayana Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <486274E1.9020106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 342 Suresh Kalale Narayana wrote: > will it affect/change sprintf/snprintf also or printf only.. The first line of the case material said so: "the printf(3C) family of functions" > its probably, good to have them in string operations also, Already answered, not this case because the other libc's don't do that. -- Darren J Moffat From Garrett.Damore@sun.com Wed Jun 25 09:40:11 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 m5PGeAkv002070 for ; Wed, 25 Jun 2008 09:40:11 -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 m5PGdtcb005772; Wed, 25 Jun 2008 17:40:08 +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 <0K310051B2AT0J00@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 10:40:05 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31004I82AS1400@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 10:40:04 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PGe4Kh002611; Wed, 25 Jun 2008 09:40:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K310040122E6K00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Wed, 25 Jun 2008 09:40:04 -0700 (PDT) Received: from [129.153.2.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31003JJ2AJXN40@fe-sfbay-09.sun.com>; Wed, 25 Jun 2008 09:39:56 -0700 (PDT) Date: Wed, 25 Jun 2008 09:39:55 -0700 From: "Garrett D'Amore" Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.29344.707553.75030@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Don Cragun , PSARC-ext@sun.com Message-id: <486274DB.802@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wiePo/dC7gDfpd0nafKBCg)" X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 3926 This is a multi-part message in MIME format. --Boundary_(ID_wiePo/dC7gDfpd0nafKBCg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James Carlson wrote: > Garrett D'Amore writes: > >> My leaning is to #1. It seems like we're trying to make bad >> applications happy, to satisfy what is probably a small minority of >> developers who feel that such use of NULL should be legal (despite >> documentation to the contrary) -- and who are unwilling to use a >> perfectly reasonable workaround, at a potential cost to the greater set >> of well-behaved applications. >> > > I think what's missing there is that this is (unfortunately) not just > a minority of developers. The bulk of user-space software looks like > this these days. People are just plain careless, and either we live > with it to make those applications "just work," or we suffer random > GNOME applications dropping core on OpenSolaris and nobody really > caring because it's "only" OpenSolaris that has this "problem." > So, I'm curious, do we have something like a hitlist somewhere of such ill-behaved applications? (And, correspondingly, a list of those applications or libraries whose maintainers have declared that they are not interested in fixing this behavior?) My fear is that by masking coding problems like this, we wind up with worse problems, which are harder to debug, later, and that we wind up "encouraging" sloppy coding practice rather than working with developers to fix the busted behavior. Is the next step really to start checking for null arguments to other string functions? What about null pointers passed to other library routines, such as free(), qsort(), bsearch()? -- Garrett --Boundary_(ID_wiePo/dC7gDfpd0nafKBCg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James Carlson wrote: 
Garrett D'Amore writes:
  
My leaning is to #1.  It seems like we're trying to make bad 
applications happy, to satisfy what is probably a small minority of 
developers who feel that such use of NULL should be legal (despite 
documentation to the contrary) -- and who are unwilling to use a 
perfectly reasonable workaround, at a potential cost to the greater set 
of well-behaved applications.
    

I think what's missing there is that this is (unfortunately) not just
a minority of developers.  The bulk of user-space software looks like
this these days.  People are just plain careless, and either we live
with it to make those applications "just work," or we suffer random
GNOME applications dropping core on OpenSolaris and nobody really
caring because it's "only" OpenSolaris that has this "problem."

So, I'm curious, do we have something like a hitlist somewhere of such ill-behaved applications?  (And, correspondingly, a list of those applications or libraries whose maintainers have declared that they are not interested in fixing this behavior?)

My fear is that by masking coding problems like this, we wind up with worse problems, which are harder to debug, later, and that we wind up "encouraging" sloppy coding practice rather than working with developers to fix the busted behavior.

Is the next step really to start checking for null arguments to other string functions?  What about null pointers passed to other library routines, such as free(), qsort(), bsearch()?

    -- Garrett

--Boundary_(ID_wiePo/dC7gDfpd0nafKBCg)-- From Stefan.Teleman@sun.com Wed Jun 25 09:47:52 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PGlqmV002418 for ; Wed, 25 Jun 2008 09:47:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PGlo72020998; Wed, 25 Jun 2008 09:47:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310030J2NQF900@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:47:50 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001KO2NP9Y40@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:47:49 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PGlnoE430470; Wed, 25 Jun 2008 09:47:49 -0700 (PDT) Date: Wed, 25 Jun 2008 12:47:48 -0400 From: Stefan Teleman Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.28392.679252.318186@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <486276B4.6090809@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> <48626A17.40707@Sun.COM> <18530.28392.679252.318186@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1486 James Carlson wrote: > Stefan Teleman writes: >> >> Darren J Moffat wrote: >> >>>> The sad thing here is that it's really the bug-ridden application code >>>> that mishandles NULL pointers that's of poor quality, so it's not >>>> OpenSolaris's reputation that should be at stake. >>> Oh I agree completely but we are the odd one out here. >> I apologize for interjecting in this discussion, but, wouldn't the character >> string "(null)" or "(nichts)" or "" being printed on stdout/stderr act as >> a clear indicator of the bug, and of its precise location ? > > Actually, no, it's not. You know its apparent location in the stdout > character stream, but nothing about where the problem might be in the > code. In other words, the fact that i see "(null)" instead of some other printable value, printed out, provides me with absolutely no indication as to which char* pointer was NULL, in the sequence of arguments passed to printf(3C) and friends. That is because I do not have a reasonably defined set of expectations with respect to what *should* be the output of printf(3C) and friends. Speaking only for myself: when i see the string "(null)" printed out, when in fact i was expecting "Giraffe", i do not think "Oh, the stdout character stream contains the string \"(null\"). How odd. I wonder what could have caused this.". I think "Why is Giraffe NULL, when it shouldn't be ?". --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gsf@research.att.com Wed Jun 25 09:49:09 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 m5PGn8v8002618 for ; Wed, 25 Jun 2008 09:49:09 -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 m5PGmxUc009717; Wed, 25 Jun 2008 17:49:05 +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 <0K31005152PRKH00@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 10:49:03 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K310043R2PQ0X10@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 10:49:03 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PGn2ao015759; Wed, 25 Jun 2008 16:49:02 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-383632; Wed, 25 Jun 2008 16:49:02 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-51356108; Wed, 25 Jun 2008 16:49:02 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1ib.sun.com with ESMTP id BT-MMP-15038144; Wed, 25 Jun 2008 16:49:02 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id CF4E7147B1B; Wed, 25 Jun 2008 12:49:01 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id m5PGn1qR014953; Wed, 25 Jun 2008 12:49:01 -0400 Date: Wed, 25 Jun 2008 12:49:01 -0400 From: Glenn Fowler Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] To: Garrett.Damore@sun.com, james.d.carlson@sun.com Cc: don.cragun@sun.com, PSARC-ext@sun.com Message-id: <200806251649.m5PGn1qR014953@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2008-02-12 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> Status: RO Content-Length: 1166 On Wed, 25 Jun 2008 12:30:24 -0400 James Carlson wrote: > Garrett D'Amore writes: > > My leaning is to #1. It seems like we're trying to make bad > > applications happy, to satisfy what is probably a small minority of > > developers who feel that such use of NULL should be legal (despite > > documentation to the contrary) -- and who are unwilling to use a > > perfectly reasonable workaround, at a potential cost to the greater set > > of well-behaved applications. > I think what's missing there is that this is (unfortunately) not just > a minority of developers. The bulk of user-space software looks like > this these days. People are just plain careless, ... this is a bit harsh people tend to code to what their local system tolerates even the most meticulous coders can fall prey to this by assuming their favorite standard implementation actually implements the standard e.g., glibc implements posix well, yes, it might, but it also makes choices on some implementation defined behavior that could be mistaken for standard behavior, sometimes even after meticulous reading of the standard -- Glenn Fowler -- AT&T Research, Florham Park NJ -- From Darren.Moffat@sun.com Wed Jun 25 09:56:10 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 m5PGu9br003094 for ; Wed, 25 Jun 2008 09:56:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PGu0J3013370; Wed, 25 Jun 2008 17:56:07 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310030T31JOO00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:56:07 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001G231H9U40@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 09:56:06 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PGu5cK024828; Wed, 25 Jun 2008 16:56:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K31005012RLLF00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 25 Jun 2008 17:56:05 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31008VD318EY80@fe-emea-09.sun.com>; Wed, 25 Jun 2008 17:55:59 +0100 (BST) Date: Wed, 25 Jun 2008 17:55:56 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <48627047.3050100@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4862789C.1050401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 4716 Garrett D'Amore wrote: > Perhaps we can have a compile-time decision, such as done with XPG4 > versus Sun definitions of things like strtok_r, where broken code is > allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch. That doesn't solve the problem. > It would then be a matter of a man page update to allow developers to > decide whether they need/want this behavior for their (broken) code. Developers on Linux and *BSD aren't reading Solaris man pages. The whole reason for this case is for making building and running existing softwar that works (regardless of what "we" think of the quality issue of passing NULL to printf) on other platforms. That means no environment variables no compile time flags, nothing. Just make our libc printf(3C) family not cause a SEGV like everyone elses, and do it all the time. > But then again, we do have 0@0.so.1, right? Right. > It *sounds* like there are two possible decisions before ARC. Either: > > 1) We continue to declare such behavior "buggy" (results undefined), and > offer workarounds ala 0@0.so.1 That basically means derailing this case and all ARC members voting against it. If that happens I'll start an appeal. > 2) We redefine the behavior such that use of NULL here is declared > permissible, and we take the hypothetized hits (if any) to performance > and debuggability. This case doesn't need to do that either. All it needs to do is what it says is does, provide the same safety net that all the other platforms libc's that were mentioned do. I purposely said in the case that there are no documentation changes because we aren't changing the documented interface just the perceived behaviour. > My leaning is to #1. It seems like we're trying to make bad > applications happy, to satisfy what is probably a small minority of No I'm trying to make OpenSolaris actually useful. I have two friends that I've convinced to run OpenSolaris rather than Ubuntu and both of them have bumped into this problem for things they have built from source. Both are seriously competent technical people and have programming skills and understand why I explainn the problem; but they don't care wither it was valid or not. What they care about is that it wouldn't have happened on Ubuntu and to them that is an OpenSolaris adoption problem - to the point that I almost lost one of them back to Ubuntu despite him being desperate to use ZFS. > developers who feel that such use of NULL should be legal (despite > documentation to the contrary) -- and who are unwilling to use a > perfectly reasonable workaround, at a potential cost to the greater set > of well-behaved applications. The workaround in my opinion isn't reasonable at all. You have to know you need it and you only find that out after you have a core file. Even if you have the core file you have to have the skills to do the analysis and realise that using the LD_PRELOAD=0@0.so.1 will help. While you and I can do that not everyone who is capable of doing: tar xf - ; ./configure ; make install is. It is those people that I'm helping. So I take that as you volunteering to fix every single upstream bit of FOSS that depends on the behaviour because it works just fine on Linux,OpenBSD,FreeBSD,NetBSD,SunOS 4.x,AIX,HP-UX. > It may be that some feel that the options presented here are an > implementation detail. But, I'm not convinced. If we feel so strongly > that we need to offer this behavior *by default* (and as the submitter > proposes, without any alternative to disable it), then we should be > willing to stand by it in the form of a documented promise. I don't think we should for the reason that Don sited. The standards say the behaviour is undefined. All the other important implementations, and even the other /usr/4lib/libc.so we still ship today, as a non destructive and completely standards compliant behaviour. IMO this is a case of purity over reality. I'm on the side of reality here. You aren't going to get me to change my mind. I was in the same camp as you for a long time but that doesn't win us new users and help OpenSolaris get to use all the same "cool" apps as everyone else. Nobody else was a way to turn this off so I don't see why we need one either. We do have DTrace which if you desire can help you find this. It is also possible that lint or valgrind or purify can help find this too. Don't punish the OpenSolaris user because of choices made by original developers of software (FOSS or closed ISV) that originate on other platforms and remember SunOS 4.x had the same behaviour this case now proposes which is probably why GNU libc has it! -- Darren J Moffat From Darren.Moffat@sun.com Wed Jun 25 10:04:10 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PH4AYN005445 for ; Wed, 25 Jun 2008 10:04:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PH489M026456; Wed, 25 Jun 2008 10:04:10 -0700 (PDT) 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 <0K310060L3EXK800@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 11:04:09 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31004N83EU0Z10@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 11:04:07 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PH46gp025355; Wed, 25 Jun 2008 17:04:06 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K310090134EUU00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 25 Jun 2008 18:04:06 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3100MUO3EEAG70@fe-emea-10.sun.com>; Wed, 25 Jun 2008 18:03:51 +0100 (BST) Date: Wed, 25 Jun 2008 18:03:49 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486274DB.802@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: James Carlson , Don Cragun , PSARC-ext@sun.com Message-id: <48627A75.6010705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1763 Garrett D'Amore wrote: > So, I'm curious, do we have something like a hitlist somewhere of such > ill-behaved applications? (And, correspondingly, a list of those > applications or libraries whose maintainers have declared that they are > not interested in fixing this behavior?) No and having such a list is pointless. Some of the cases are in things that are currently in Solaris/OpenSolaris (the GNOME examples) but others are in things that aren't and might never be. It is just the state of the world. > My fear is that by masking coding problems like this, we wind up with > worse problems, which are harder to debug, later, and that we wind up > "encouraging" sloppy coding practice rather than working with developers > to fix the busted behavior. That IMO is a silly stance. Every other UNIX platform that still matters (Linux and all other GNU libc systems, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX) all behave the way this case proposes and without any debug traps. > Is the next step really to start checking for null arguments to other > string functions? What about null pointers passed to other library > routines, such as free(), qsort(), bsearch()? Not this case it isn't and I have no such plans. This case is about fixing the pain that OpenSolaris users feel when attempting to build and/or run stuff outside of OpenSolaris. It is a about helping OpenSolaris grow by allowing us to ship those programs wihtout having huge arguments with the upstream community that frankly we have near zero chance of winning in many cases. I'm done with justifying this and discussing it we are just going around in circles covering stuff that was in the original proposal. Either derail or let this finish. -- Darren J Moffat From Nicolas.Williams@Sun.COM Wed Jun 25 10:08:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PH8iqG007112 for ; Wed, 25 Jun 2008 10:08:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PH7g4P010618; Thu, 26 Jun 2008 01:08:39 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100M073MF8C00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 10:08:39 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100GPV3MEJ340@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 10:08:39 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5PH8cLu002220; Wed, 25 Jun 2008 12:08:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5PH8c6H002219; Wed, 25 Jun 2008 12:08:38 -0500 (CDT) Date: Wed, 25 Jun 2008 12:08:38 -0500 From: Nicolas Williams Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486274DB.802@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Don Cragun , PSARC-ext@Sun.COM Mail-followup-to: Garrett D'Amore , James Carlson , Don Cragun , PSARC-ext@sun.com Message-id: <20080625170838.GT2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 728 On Wed, Jun 25, 2008 at 09:39:55AM -0700, Garrett D'Amore wrote: > Is the next step really to start checking for null arguments to other > string functions? What about null pointers passed to other library > routines, such as free(), qsort(), bsearch()? free(NULL) is already allowed, always. To provide a general answer: if it were to turn out that, say, strlen(NULL) "works" (e.g., returns 0) on Linux and *BSD and that *many* applications depend on this behaviour, then we may have to consider making our strlen() do the same. If this were to violate some standard, then that will complicate the decision process -- we may need to resort to compile-/link-time behaviour selections (for libraries and executables both). From carlsonj@phorcys.east.sun.com Wed Jun 25 10:15:25 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PHFPht007780 for ; Wed, 25 Jun 2008 10:15:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PHFNap008472; Wed, 25 Jun 2008 10:15:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K31004053XMAQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 10:15:22 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K310012S3XL9Y60@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 10:15:22 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PH7pWA008534; Wed, 25 Jun 2008 13:07:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PH7p9e008531; Wed, 25 Jun 2008 13:07:51 -0400 (EDT) Date: Wed, 25 Jun 2008 13:07:51 -0400 From: James Carlson Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486276B4.6090809@Sun.COM> To: Stefan Teleman , Glenn Fowler Cc: Darren J Moffat , PSARC-ext@sun.com, Garrett.Damore@sun.com, don.cragun@sun.com Message-id: <18530.31591.667158.985749@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <200806251649.m5PGn1qR014953@penguin.research.att.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> <48626A17.40707@Sun.COM> <18530.28392.679252.318186@gargle.gargle.HOWL> <486276B4.6090809@Sun.COM> Status: RO Content-Length: 3188 Stefan Teleman writes: > > Actually, no, it's not. You know its apparent location in the stdout > > character stream, but nothing about where the problem might be in the > > code. > > In other words, the fact that i see "(null)" instead of some other printable > value, printed out, provides me with absolutely no indication as to which char* > pointer was NULL, in the sequence of arguments passed to printf(3C) and friends. In many cases, it doesn't tell you which executable was involved, or which loadable module in that executable, or anything about the conditions that caused the problem. > Speaking only for myself: when i see the string "(null)" printed out, when in > fact i was expecting "Giraffe", i do not think "Oh, the stdout character stream > contains the string \"(null\"). How odd. I wonder what could have caused this.". > > I think "Why is Giraffe NULL, when it shouldn't be ?". I suspect that's because you may be the developer of that software, and thus know the locations and contents of the printf() strings themselves. Try it as a user: Installing software modules. Unable to load module (null). Operation complete; 327 modules loaded. Does that tell you anything useful? What executable failed? Was it a library function or the main program? Could it have been one of the modules that was (apparently) being loaded by way of dlopen? It may as well have said "somthing bad happened." Glenn Fowler writes: > On Wed, 25 Jun 2008 12:30:24 -0400 James Carlson wrote: > > I think what's missing there is that this is (unfortunately) not just > > a minority of developers. The bulk of user-space software looks like > > this these days. People are just plain careless, ... > > this is a bit harsh > people tend to code to what their local system tolerates I've thought about it a bit, and I'm going to stand by it. Even if your system 'tolerates' something as an implementation artifact, that doesn't make it right. In order for this to be something other than simple carelessness, I think the developer would have had to have seen that "(null)" output, and decided, "eh, that's good enough." If that's what happened, then what I wrote isn't probably harsh enough. > e.g., glibc implements posix > well, yes, it might, but it also makes choices on some implementation defined behavior > that could be mistaken for standard behavior, sometimes even after > meticulous reading of the standard Regardless of whether glibc implements POSIX, I don't think that ignoring bad pointers is good programming practice. Perhaps it's just my opinion alone, but I think failing to consider whether a pointer ought to be NULL and doing something about it reflects a lack of due care. Sure; that can affect anyone. If you find it in my code, feel free to point the example out as an instance of carelessness on my part. (I'm not seeking a Gary Hart moment here, but rather saying that I don't think the criticism is unfair.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From bart.smaalders@sun.com Wed Jun 25 10:31:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PHV73j008802 for ; Wed, 25 Jun 2008 10:31:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PHV36v004897; Wed, 25 Jun 2008 10:31:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310010D4NRCE00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 10:31:03 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100G3M4NQIX60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 10:31:02 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m5PHV2x7018096; Wed, 25 Jun 2008 17:31:02 +0000 (GMT) Date: Wed, 25 Jun 2008 10:31:02 -0700 From: Bart Smaalders Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.31591.667158.985749@gargle.gargle.HOWL> To: James Carlson Cc: Stefan Teleman , Glenn Fowler , Darren J Moffat , PSARC-ext@sun.com, Garrett.Damore@sun.com, don.cragun@sun.com Message-id: <486280D6.4060508@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <200806251649.m5PGn1qR014953@penguin.research.att.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> <48626A17.40707@Sun.COM> <18530.28392.679252.318186@gargle.gargle.HOWL> <486276B4.6090809@Sun.COM> <18530.31591.667158.985749@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 1257 James Carlson wrote: > Regardless of whether glibc implements POSIX, I don't think that > ignoring bad pointers is good programming practice. Perhaps it's just > my opinion alone, but I think failing to consider whether a pointer > ought to be NULL and doing something about it reflects a lack of due > care. Indeed... but we're just being particularly picky in about printf... in the libc malloc implementation, we were far more accommodating of broken programs - the existing implementation allows the same pointer to be freed multiple times (so long as there was no intervening call to {re,m,c}alloc), and realloc works if given a pointer that was already freed. These are much more pernicious and dangerous than allowing a NULL pointer to be passed to "%s" format specifiers. Also, we print NaN when an illegal floating point number is passed to printf rather tjhan just raising a FP exception. We can either choose to be compatible w/ virtually everyone else, or we can continue to be particular about printf's string arguments. Personally, I'd vote for compatibility. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gsf@research.att.com Wed Jun 25 10:33:05 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 m5PHX5cq008867 for ; Wed, 25 Jun 2008 10:33:05 -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 m5PHWqFG002212; Wed, 25 Jun 2008 18:33:00 +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 <0K310080H4QZLR00@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 11:32:59 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31004K44QX0V30@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 11:32:57 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PHUWkr025829; Wed, 25 Jun 2008 17:32:57 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-1189006; Wed, 25 Jun 2008 17:32:56 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-253420; Wed, 25 Jun 2008 17:32:56 +0000 (Z) Received: from mail-yellow.research.att.com ([192.20.225.112] [192.20.225.112]) by relay1ib.sun.com with ESMTP id BT-MMP-15057942; Wed, 25 Jun 2008 17:32:56 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id 16450147B1B; Wed, 25 Jun 2008 13:32:56 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id m5PHWt1T017543; Wed, 25 Jun 2008 13:32:55 -0400 Date: Wed, 25 Jun 2008 13:32:55 -0400 From: Glenn Fowler Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] To: gsf@research.att.com, james.d.carlson@sun.com, Stefan.Teleman@sun.com Cc: Darren.Moffat@sun.com, don.cragun@sun.com, Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <200806251732.m5PHWt1T017543@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2008-02-12 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.058sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <200806251649.m5PGn1qR014953@penguin.research.att.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> <48626A17.40707@Sun.COM> <18530.28392.679252.318186@gargle.gargle.HOWL> <486276B4.6090809@Sun.COM> <18530.31591.667158.985749@gargle.gargle.HOWL> Status: RO Content-Length: 1227 On Wed, 25 Jun 2008 13:07:51 -0400 James Carlson wrote: > Glenn Fowler writes: > > On Wed, 25 Jun 2008 12:30:24 -0400 James Carlson wrote: > > > I think what's missing there is that this is (unfortunately) not just > > > a minority of developers. The bulk of user-space software looks like > > > this these days. People are just plain careless, ... > > > > this is a bit harsh > > people tend to code to what their local system tolerates > I've thought about it a bit, and I'm going to stand by it. Even if > your system 'tolerates' something as an implementation artifact, that > doesn't make it right. > In order for this to be something other than simple carelessness, I > think the developer would have had to have seen that "(null)" output, > and decided, "eh, that's good enough." If that's what happened, then > what I wrote isn't probably harsh enough. as is this case with many of my bugs, they are data dependent and my regression tests never hit all of the cases cooked up by ingenous users so instead of "eh, that's good enough" its "didn't think of that" and "the next release will have a fix and companion test(s)" -- different from "carelessness" -- Glenn Fowler -- AT&T Research, Florham Park NJ -- From Gordon.Ross@Sun.COM Wed Jun 25 10:52:51 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PHqow1009289 for ; Wed, 25 Jun 2008 10:52:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PHqlfe029025 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Jun 2008 01:52:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310050Z5O1M600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 10:52:49 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001JN5NZA370@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 10:52:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PHql7v000986 for ; Wed, 25 Jun 2008 17:52:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K31001014R5ZZ00@mail-amer.sun.com> (original mail from Gordon.Ross@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 11:52:47 -0600 (MDT) Received: from [129.148.168.158] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3100AWN5NU5680@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 11:52:43 -0600 (MDT) Date: Wed, 25 Jun 2008 13:52:41 -0400 From: Gordon Ross Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486265AD.9040103@Sun.COM> Sender: Gordon.Ross@Sun.COM To: Darren J Moffat Cc: PSARC-ext@Sun.COM Message-id: <1214416361.1029.31.camel@acer-gwr> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <486265AD.9040103@Sun.COM> Status: RO Content-Length: 2166 Darren Moffat wrote: > James Carlson wrote: [...] > > So, with this one under our belts, should we also fix up the > str*(3C) > > family of functions so that they quietly ignore NULL pointers as > well? > > The goal of this case was parity with the other mentioned libc > implementations. I have looked at what the others do for strlen(NULL) > and they will SEGV on that. I haven't looked at every str*(3C) > function. That's fine, but FYI, the Microsoft C runtime does this substitution of "" for NULL in the str* functions. (Or they used to. I haven't tried recently.) > > An application that's incautious with NULL can't possibly just make > > that mistake with printf alone, can it? > > Probably not but this is a "safety net" that is available on other > platforms. Similar saftey nets for the str*(3C) functions don't at > initial glance appear to exist. > > If the applicaiton/lib is that free and loose with NULL then we still > have the ability to LD_PRELOAD=0@0.so.1 if the code can't be fixed. And for the record, that is not a sufficient solution, because then you won't trap on other errant NULL pointers. But again, OK, not this case. > This case is about fixing the very commonly encountered case and the > case were Solaris is disastrously different to the common platforms. > > > Is NULL the only bad pointer worth caring about? What sorts of bad > > pointer checks need to be made so that malfunctioning applications > can > > continue running without dropping core? How deep does the rabbit > hole > > go? > > The Rabbit hole is very deep but this case is just about getting > dinner > for tonight, someone else can explore the rest of the warren. Understood. Later discussion is concerned with what to replace the null pointer with. Here's a suggestion for that: In libc:printf #pragma weak _printf_null_str_replacment() const char * _printf_null_str_replacement() { return (""); } and in printf if (str_ptr == NULL) str_ptr = _printf_null_str_replacement(); and then let whatever links with libc provide something different if it wants to. I.e. to get SIGSEGV: provide a function that returns NULL instead. From Garrett.Damore@sun.com Wed Jun 25 10:55:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PHtgLh009613 for ; Wed, 25 Jun 2008 10:55:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PHteFO018388; Wed, 25 Jun 2008 11:55:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K31005015STQ100@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 10:55:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001G35SS9U90@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 10:55:40 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PHtefC005125; Wed, 25 Jun 2008 10:55:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3100M0152IE200@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM); Wed, 25 Jun 2008 10:55:40 -0700 (PDT) Received: from [129.153.2.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31003VF5SRXNA0@fe-sfbay-09.sun.com>; Wed, 25 Jun 2008 10:55:40 -0700 (PDT) Date: Wed, 25 Jun 2008 10:55:39 -0700 From: "Garrett D'Amore" Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862789C.1050401@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Don Cragun , PSARC-ext@sun.com Message-id: <4862869B.2020406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <4862789C.1050401@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 5142 As a compromise, can we have a way to enable the old behavior, and have that behavior enabled by default for all of the code that Sun ships? (I'm talking about an alternate implementation, enabled in the headers via a #define or somesuch.) -- Garrett Darren J Moffat wrote: > Garrett D'Amore wrote: >> Perhaps we can have a compile-time decision, such as done with XPG4 >> versus Sun definitions of things like strtok_r, where broken code is >> allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch. > > That doesn't solve the problem. > >> It would then be a matter of a man page update to allow developers to >> decide whether they need/want this behavior for their (broken) code. > > Developers on Linux and *BSD aren't reading Solaris man pages. The > whole reason for this case is for making building and running existing > softwar that works (regardless of what "we" think of the quality issue > of passing NULL to printf) on other platforms. > > That means no environment variables no compile time flags, nothing. > Just make our libc printf(3C) family not cause a SEGV like everyone > elses, and do it all the time. > > >> But then again, we do have 0@0.so.1, right? > > Right. > > >> It *sounds* like there are two possible decisions before ARC. Either: >> >> 1) We continue to declare such behavior "buggy" (results undefined), >> and offer workarounds ala 0@0.so.1 > > That basically means derailing this case and all ARC members voting > against it. > > If that happens I'll start an appeal. > >> 2) We redefine the behavior such that use of NULL here is declared >> permissible, and we take the hypothetized hits (if any) to >> performance and debuggability. > > This case doesn't need to do that either. All it needs to do is what > it says is does, provide the same safety net that all the other > platforms libc's that were mentioned do. > > I purposely said in the case that there are no documentation changes > because we aren't changing the documented interface just the perceived > behaviour. > >> My leaning is to #1. It seems like we're trying to make bad >> applications happy, to satisfy what is probably a small minority of > > No I'm trying to make OpenSolaris actually useful. I have two friends > that I've convinced to run OpenSolaris rather than Ubuntu and both of > them have bumped into this problem for things they have built from > source. Both are seriously competent technical people and have > programming skills and understand why I explainn the problem; but they > don't care wither it was valid or not. What they care about is that > it wouldn't have happened on Ubuntu and to them that is an OpenSolaris > adoption problem - to the point that I almost lost one of them back to > Ubuntu despite him being desperate to use ZFS. > >> developers who feel that such use of NULL should be legal (despite >> documentation to the contrary) -- and who are unwilling to use a >> perfectly reasonable workaround, at a potential cost to the greater >> set of well-behaved applications. > > The workaround in my opinion isn't reasonable at all. You have to > know you need it and you only find that out after you have a core > file. Even if you have the core file you have to have the skills to > do the analysis and realise that using the LD_PRELOAD=0@0.so.1 will > help. While you and I can do that not everyone who is capable of > doing: tar xf - ; ./configure ; make install is. It is those people > that I'm helping. > > So I take that as you volunteering to fix every single upstream bit of > FOSS that depends on the behaviour because it works just fine on > Linux,OpenBSD,FreeBSD,NetBSD,SunOS 4.x,AIX,HP-UX. > >> It may be that some feel that the options presented here are an >> implementation detail. But, I'm not convinced. If we feel so >> strongly that we need to offer this behavior *by default* (and as the >> submitter proposes, without any alternative to disable it), then we >> should be willing to stand by it in the form of a documented promise. > > I don't think we should for the reason that Don sited. The standards > say the behaviour is undefined. All the other important > implementations, and even the other /usr/4lib/libc.so we still ship > today, as a non destructive and completely standards compliant behaviour. > > IMO this is a case of purity over reality. I'm on the side of reality > here. > > You aren't going to get me to change my mind. I was in the same camp > as you for a long time but that doesn't win us new users and help > OpenSolaris get to use all the same "cool" apps as everyone else. > > Nobody else was a way to turn this off so I don't see why we need one > either. We do have DTrace which if you desire can help you find > this. It is also possible that lint or valgrind or purify can help > find this too. > > Don't punish the OpenSolaris user because of choices made by original > developers of software (FOSS or closed ISV) that originate on other > platforms and remember SunOS 4.x had the same behaviour this case now > proposes which is probably why GNU libc has it! > From Jyri.Virkki@sun.com Wed Jun 25 11:59:27 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 m5PIxQ0r011513 for ; Wed, 25 Jun 2008 11:59:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PIxFrl012618; Wed, 25 Jun 2008 19:59:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K31008098QX5I00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 11:59:21 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31001OH8QW9WE0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 11:59:21 -0700 (PDT) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PIxJh5002281; Wed, 25 Jun 2008 18:59:20 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id m5PIxJs22114; Wed, 25 Jun 2008 11:59:19 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m5PIxJNW017331; Wed, 25 Jun 2008 11:59:19 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m5PIxJBV017330; Wed, 25 Jun 2008 11:59:19 -0700 (PDT) Date: Wed, 25 Jun 2008 11:59:19 -0700 From: Jyri Virkki Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <486274DB.802@sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> To: Darren J Moffat , PSARC-ext@sun.com Message-id: <20080625185919.GF14536@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 2344 Another ARC gone wild thread? Can we keep the lessons of the past months in mind? I read the materials and there are no exported interface changes, no imported interface changes and not even any documentation changes. Only an implementation change to something formally defined as undefined, so while your code reviewers should have something to say if the implementation chooses to, say, reboot the system, code reviews are not in scope for ARC. So there's actually nothing for ARC to review here.. why file this case? My vote is you close it approved automatic and go fix the bug already. Everything below is just me adding to the noise, so ignore for "this case" purposes. James Carlson wrote: > > An application that's incautious with NULL can't possibly just make > that mistake with printf alone, can it? They're not being incautious with NULLs, they (C developers) do it because printf is known and documented to handle it. Oh, not on OpenSolaris? Too bad for us, nobody cares. A great way to make people avoid adopting OpenSolaris is to make sure the apps they run succesfully everywhere else crash only on OpenSolaris. GNU printf is documented to print '(null)', so no big surprise developers rely on documented behavior. "If you accidentally pass a null pointer as the argument for a `%s' conversion, the GNU library prints it as `(null)'. We think this is more useful than crashing." http://www.gnu.org/software/libtool/manual/libc/Other-Output-Conversions.html (The text goes on to say "But it's not good practice to pass a null argument intentionally" but in true human/developer nature, people don't pay attention that that. Once the behavior has been promised and implemented, people will use it.) Garrett D'Amore wrote: > > Is the next step really to start checking for null arguments to other > string functions? What about null pointers passed to other library > routines, such as free(), qsort(), bsearch()? I didn't see Darren propose that so "not this case". But if you'd like to go research all those functions to see if there are some other areas where there is a serious disconnect between the defacto industry standards and the OpenSolaris implementation, hurting OpenSolaris adoption, it would be useful info to share later. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Manoj@sun.com Wed Jun 25 12:15:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PJFSWr011884 for ; Wed, 25 Jun 2008 12:15:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PJFP76029773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Jun 2008 03:15:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100B079HOSI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 12:15:24 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100G9G9HNIVF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 12:15:24 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PJFmWo010382 for ; Wed, 25 Jun 2008 19:15:48 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K3100L019G8UE00@mail-apac.sun.com> (original mail from Manoj@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Jun 2008 03:14:57 +0800 (SGT) Received: from [192.168.2.3] ([76.120.41.119]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K3100MX79GVLR8Q@mail-apac.sun.com>; Thu, 26 Jun 2008 03:14:57 +0800 (SGT) Date: Wed, 25 Jun 2008 13:15:17 -0600 From: Manoj Joseph Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <18530.22339.958793.184491@gargle.gargle.HOWL> Sender: Manoj.Joseph@sun.com To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <48629945.7020602@Sun.COM> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 747 James Carlson wrote: > The sad thing here is that it's really the bug-ridden application code > that mishandles NULL pointers that's of poor quality, so it's not > OpenSolaris's reputation that should be at stake. This is unfortunately not always true. There are programs out there (often, initially written for Linux) that assume that printf(3C) prints out "null" and not segfault. Take for instance, Lustre. It has debug print macros that assumes this behavior. And using /usr/lib/0@0.so.1 hides real bugs. One way to fix it is to change the calls at hundreds of places. Another is to ship a version of printf that does the 'right thing' of printing "null". ;) Just my $0.02. Regards, Manoj -- Manoj Joseph, Lustre Group, Sun Microsystems From jek3@sun.com Wed Jun 25 12:17:50 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 m5PJHnDd011914 for ; Wed, 25 Jun 2008 12:17:50 -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 m5PJHhq3020863; Wed, 25 Jun 2008 20:17:47 +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 <0K3100G099LK0700@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 13:17:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31004PV9LK1A90@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 13:17:44 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PJHf6K463236; Wed, 25 Jun 2008 12:17:41 -0700 (PDT) Date: Wed, 25 Jun 2008 09:20:54 -1000 From: Joseph Kowalski Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <20080625185919.GF14536@sun.com> To: Jyri Virkki Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <48629A96.2090800@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <20080625185919.GF14536@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 223 Jyri Virkki wrote: > I read the materials and there are no exported interface changes, no > imported interface changes and not even any documentation changes. > Sigh,... But its a very visible semantic change. - jek3 From Garrett.Damore@Sun.COM Wed Jun 25 12:29:22 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PJTL6k012028 for ; Wed, 25 Jun 2008 12:29:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PJTJs9004816 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Jun 2008 03:29:21 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K310090PA4UBS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 12:29:18 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31008BMA4TYK30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 12:29:17 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PJTHGF017334 for ; Wed, 25 Jun 2008 12:29:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3100501A03I900@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 25 Jun 2008 12:29:17 -0700 (PDT) Received: from [129.153.2.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K310072GA4SL100@fe-sfbay-10.sun.com>; Wed, 25 Jun 2008 12:29:17 -0700 (PDT) Date: Wed, 25 Jun 2008 12:29:16 -0700 From: "Garrett D'Amore" Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <20080625185919.GF14536@sun.com> Sender: Garrett.Damore@Sun.COM To: Jyri Virkki Cc: Darren J Moffat , PSARC-ext@Sun.COM Message-id: <48629C8C.9030301@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_td4HGQ/B8F8s7SbftAFIrQ)" X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <20080625185919.GF14536@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 6288 This is a multi-part message in MIME format. --Boundary_(ID_td4HGQ/B8F8s7SbftAFIrQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Jyri Virkki wrote: > Another ARC gone wild thread? Can we keep the lessons of the past > months in mind? > > I read the materials and there are no exported interface changes, no > imported interface changes and not even any documentation changes. > > Only an implementation change to something formally defined as > undefined, so while your code reviewers should have something to say > if the implementation chooses to, say, reboot the system, code reviews > are not in scope for ARC. > > So there's actually nothing for ARC to review here.. why file this case? > My vote is you close it approved automatic and go fix the bug already. > > > I think someone else commented on the potential for changes in debuggability and performance. ARC review is not inappropriate. > > > > Everything below is just me adding to the noise, so ignore for "this > case" purposes. > > James Carlson wrote: > >> An application that's incautious with NULL can't possibly just make >> that mistake with printf alone, can it? >> > > They're not being incautious with NULLs, they (C developers) do it > because printf is known and documented to handle it. > > Oh, not on OpenSolaris? Too bad for us, nobody cares. A great way to > make people avoid adopting OpenSolaris is to make sure the apps they > run succesfully everywhere else crash only on OpenSolaris. > > GNU printf is documented to print '(null)', so no big surprise > developers rely on documented behavior. > > "If you accidentally pass a null pointer as the argument for a `%s' > conversion, the GNU library prints it as `(null)'. We think this is > more useful than crashing." > > http://www.gnu.org/software/libtool/manual/libc/Other-Output-Conversions.html > > (The text goes on to say "But it's not good practice to pass a null > argument intentionally" but in true human/developer nature, people > don't pay attention that that. Once the behavior has been promised and > implemented, people will use it.) > So if this is the case, then lets just follow suit. But lets do so explicitly, with similar language in our printf() documentation, rather than just silently doing something. I'd assume for "familiarity" that the same "(null)" string should be used, as well. Admittedly, I'm not thrilled with this (I want my cycles back!) but I'm OK with it, particularly if we just go ahead and document it as an acceptable practice. (In particular, I'm thinking about all the cases of (x ? x : "null") that are in debug statements around. If you're going to make me burn the cycles to make the test in libc, at least let me reclaim them in my other code. :-) -- Garrett --Boundary_(ID_td4HGQ/B8F8s7SbftAFIrQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Jyri Virkki wrote: 
Another ARC gone wild thread? Can we keep the lessons of the past
months in mind?

I read the materials and there are no exported interface changes, no
imported interface changes and not even any documentation changes.

Only an implementation change to something formally defined as
undefined, so while your code reviewers should have something to say
if the implementation chooses to, say, reboot the system, code reviews
are not in scope for ARC.

So there's actually nothing for ARC to review here.. why file this case?
My vote is you close it approved automatic and go fix the bug already.

I think someone else commented on the potential for changes in debuggability and performance.  ARC review is not inappropriate.




Everything below is just me adding to the noise, so ignore for "this
case" purposes.

James Carlson wrote:
  
An application that's incautious with NULL can't possibly just make
that mistake with printf alone, can it?
    

They're not being incautious with NULLs, they (C developers) do it
because printf is known and documented to handle it.

Oh, not on OpenSolaris?  Too bad for us, nobody cares. A great way to
make people avoid adopting OpenSolaris is to make sure the apps they
run succesfully everywhere else crash only on OpenSolaris.

GNU printf is documented to print '(null)', so no big surprise
developers rely on documented behavior.

  "If you accidentally pass a null pointer as the argument for a `%s'
  conversion, the GNU library prints it as `(null)'. We think this is
  more useful than crashing."

http://www.gnu.org/software/libtool/manual/libc/Other-Output-Conversions.html

(The text goes on to say "But it's not good practice to pass a null
argument intentionally" but in true human/developer nature, people
don't pay attention that that. Once the behavior has been promised and
implemented, people will use it.)

So if this is the case, then lets just follow suit.  But lets do so explicitly, with similar language in our printf() documentation, rather than just silently doing something.  I'd assume for "familiarity" that the same "(null)" string should be used, as well.

Admittedly, I'm not thrilled with this (I want my cycles back!) but I'm OK with it, particularly if we just go ahead and document it as an acceptable practice.  (In particular, I'm thinking about all the cases of (x ? x : "null") that are in debug statements around.  If you're going to make me burn the cycles to make the test in libc, at least let me reclaim them in my other code. :-)

    -- Garrett

--Boundary_(ID_td4HGQ/B8F8s7SbftAFIrQ)-- From Nicolas.Williams@sun.com Wed Jun 25 12:41:53 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PJfqJR012150 for ; Wed, 25 Jun 2008 12:41:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PJfpPI051210; Wed, 25 Jun 2008 13:41:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100E01APRM000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 12:41:51 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100ELXAPR5D00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jun 2008 12:41:51 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5PJfosv002348; Wed, 25 Jun 2008 14:41:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5PJfoQA002347; Wed, 25 Jun 2008 14:41:50 -0500 (CDT) Date: Wed, 25 Jun 2008 14:41:49 -0500 From: Nicolas Williams Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <48629A96.2090800@sun.com> To: Joseph Kowalski Cc: Jyri Virkki , Darren J Moffat , PSARC-ext@sun.com Mail-followup-to: Joseph Kowalski , Jyri Virkki , Darren J Moffat , PSARC-ext@sun.com Message-id: <20080625194149.GW2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <20080625185919.GF14536@sun.com> <48629A96.2090800@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 353 On Wed, Jun 25, 2008 at 09:20:54AM -1000, Joseph Kowalski wrote: > Jyri Virkki wrote: > >I read the materials and there are no exported interface changes, no > >imported interface changes and not even any documentation changes. > > > Sigh,... > > But its a very visible semantic change. Yes: it lets certain apps run! :) Note: no tongue in cheek. From Richard.Matthews@sun.com Wed Jun 25 13:45:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PKjpp9014883 for ; Wed, 25 Jun 2008 13:45:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PKjnhU001119 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Jun 2008 04:45:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100L03DODGT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 13:45:49 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100EPXDOD5O80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 13:45:49 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PKjnnt017851 for ; Wed, 25 Jun 2008 20:45:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3100401B8TO400@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 14:45:49 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31002WADO8B390@mail-amer.sun.com>; Wed, 25 Jun 2008 14:45:45 -0600 (MDT) Date: Wed, 25 Jun 2008 15:45:44 -0500 From: Rick Matthews Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <20080625194149.GW2735@Sun.COM> Sender: Richard.Matthews@sun.com To: Joseph Kowalski , Jyri Virkki , Darren J Moffat , PSARC-ext@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <4862AE78.7020006@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_B5ae2a2Q8u7Sl6Qior1B9w)" X-PMX-Version: 5.4.1.325704 References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <20080625185919.GF14536@sun.com> <48629A96.2090800@sun.com> <20080625194149.GW2735@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 3943 This is a multi-part message in MIME format. --Boundary_(ID_B5ae2a2Q8u7Sl6Qior1B9w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: > On Wed, Jun 25, 2008 at 09:20:54AM -1000, Joseph Kowalski wrote: > >> Jyri Virkki wrote: >> >>> I read the materials and there are no exported interface changes, no >>> imported interface changes and not even any documentation changes. >>> >>> >> Sigh,... >> >> But its a very visible semantic change. >> > > Yes: it lets certain apps run! > > :) > > Note: no tongue in cheek. > About the fast track length and protocol: I picked Nico's message to reply for no particular reason except the header should ensure it be recorded properly (note: use the ARC ans case as part of the header). This thread is also getting a bit long. Darren, is it time to make it a discussion at PSARC rather than a email trail. About the case: It seems to me this is about being bug compatible with other implementations. This one doesn't seem particularly offensive. WRT compatibility, is this more a "gang of four" issue as to whether this is the "familiarity" we want? -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_B5ae2a2Q8u7Sl6Qior1B9w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: 
On Wed, Jun 25, 2008 at 09:20:54AM -1000, Joseph Kowalski wrote:
  
Jyri Virkki wrote:
    
I read the materials and there are no exported interface changes, no
imported interface changes and not even any documentation changes.
 
      
Sigh,...

But its a very visible semantic change.
    

Yes: it lets certain apps run!

:)

Note: no tongue in cheek.
About the fast track length and protocol:

I picked Nico's message to reply for no particular reason except the
header should ensure it be recorded properly (note: use the ARC ans
case as part of the header).

This thread is also getting a bit long. Darren, is it time to make it a
discussion at PSARC rather than a email trail.

About the case:

It seems to me this is about being bug compatible with other implementations.
This one doesn't seem particularly offensive. WRT compatibility, is this more
a "gang of four" issue as to whether this is the "familiarity" we want?

-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_B5ae2a2Q8u7Sl6Qior1B9w)-- From glenn.skinner@sun.com Wed Jun 25 14:01:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PL1B7R015866 for ; Wed, 25 Jun 2008 14:01:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5PL16Rw006404; Thu, 26 Jun 2008 05:01:08 +0800 (SGT) 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 <0K310000PEDTN500@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 15:01:05 -0600 (MDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100403EDT18F0@brm-avmta-1.central.sun.com>; Wed, 25 Jun 2008 15:01:05 -0600 (MDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m5PL149a015108; Wed, 25 Jun 2008 14:01:04 -0700 (PDT) Date: Wed, 25 Jun 2008 14:01:04 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/403 [libc printf behaviour for NULL string] To: Jyri.Virkki@sun.com, darrenm@sac.sfbay.sun.com, PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: kZnh0BpGvAo5w4oOAxbWqw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 840 Date: Wed, 25 Jun 2008 15:45:44 -0500 From: Rick Matthews Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] ... About the case: It seems to me this is about being bug compatible with other implementations. This one doesn't seem particularly offensive. WRT compatibility, is this more a "gang of four" issue as to whether this is the "familiarity" we want? Speaking both as a PSARC member and a "gang" of four member, yes, this case definitely helps achieve the sort of familiarity we're aiming for. From my perspective, it's a no-brainer. I was a charter member of the purity camp whose position I see many of the posters to this case arguing. But that kind of purity is a luxury we can no longer afford. -- Glenn From jek3@sun.com Wed Jun 25 14:51:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PLpW26020103 for ; Wed, 25 Jun 2008 14:51:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5PLpT83021444; Wed, 25 Jun 2008 15:51:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100F05GPVA300@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 14:51:31 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100A7PGPUKP80@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 14:51:30 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PLpTRm489410; Wed, 25 Jun 2008 14:51:29 -0700 (PDT) Date: Wed, 25 Jun 2008 11:54:42 -1000 From: Joseph Kowalski Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: Jyri.Virkki@sun.com, darrenm@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <4862BEA2.8050606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 216 Darren (several timezones removed), When you get through this tread, I need your position (as submitter) on the proposed binding of Patch. From there, I can decide what to do with this case. - thanks, - jek3 From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 26 01:43:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5Q8htjf008869 for ; Thu, 26 Jun 2008 01:43:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5Q8hoA9018791; Thu, 26 Jun 2008 16:43:51 +0800 (SGT) 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 <0K320090JAX04Q00@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 02:43:48 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K32000NTAWZBRE0@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 02:43:47 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5Q8hkDO022577; Thu, 26 Jun 2008 08:43:46 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-420000; Thu, 26 Jun 2008 08:43:46 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-52344830; Thu, 26 Jun 2008 08:43:44 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1ib.sun.com with ESMTP id BT-MMP-4564819; Thu, 26 Jun 2008 08:43:44 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw25] (8.14.2+/8.14.2) with ESMTP id m5Q8hhuo012937; Thu, 26 Jun 2008 10:43:43 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5Q8hhTi012931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2008 10:43:43 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5Q8hhKk020169; Thu, 26 Jun 2008 10:43:43 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 10:43:43 +0200 Date: Thu, 26 Jun 2008 10:43:42 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862612E.3070006@Sun.COM> To: Garrett.Damore@sun.com, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com Message-id: <486356be.h9HPC4vqCHohMXhm%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <4862589D.60109@sun.com> <4862612E.3070006@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 26 Jun 2008 08:43:43.0278 (UTC) FILETIME=[BD5034E0:01C8D768] Status: RO Content-Length: 772 Darren J Moffat wrote: > I don't think that is a good idea. None of the other platforms I viewed > have this and we didn't have this with SunOS 4.x either. More > importantly I don't like the idea of having to check an environment > variable on every printf(3C) family call, there could be a noticable > performance hit for that. If you only do it in case of a error situation like a passed NULL pointer, I cannot see a perfoemance problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 26 01:49:12 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 m5Q8nCV2008883 for ; Thu, 26 Jun 2008 01:49:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5Q8n8vY005870; Thu, 26 Jun 2008 09:49:10 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3200L0PB5WCZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 01:49:08 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3200JZ5B5VA140@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 01:49:08 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5Q8eJHD009436; Thu, 26 Jun 2008 08:49:07 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay16i.sun.com with ESMTP id BT-MMP-1216354; Thu, 26 Jun 2008 08:49:06 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-303868; Thu, 26 Jun 2008 08:49:06 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1ib.sun.com with ESMTP id BT-MMP-4694966; Thu, 26 Jun 2008 08:49:06 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw23] (8.14.2+/8.14.2) with ESMTP id m5Q8n0p5025899; Thu, 26 Jun 2008 10:49:00 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5Q8n0RU025894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2008 10:49:00 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5Q8mxNo020409; Thu, 26 Jun 2008 10:48:59 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 10:48:59 +0200 Date: Thu, 26 Jun 2008 10:48:59 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862654D.3050801@Egenera.COM> To: KMcDonald@egenera.com, James.D.Carlson@sun.com Cc: PSARC-ext@sun.com, darrenm@sac.sfbay.sun.com Message-id: <486357fb.LQ1OjRTYPt3aTvta%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.065sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251412.m5PEC6Xe025866@sac.sfbay.sun.com> <18530.22339.958793.184491@gargle.gargle.HOWL> <4862654D.3050801@Egenera.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 26 Jun 2008 08:48:59.0673 (UTC) FILETIME=[79E64090:01C8D769] Status: RO Content-Length: 633 Kyle McDonald wrote: > If memory serves, I seem to remember at least one platform (can't recall > which) where passing a NULL pointer as a string to printf actually > caused printf to print the string "". I have not seen this but UNOS did print "(NULL POINTER)" and my own printf() does the same. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 26 02:10:26 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5Q9AQjr011010 for ; Thu, 26 Jun 2008 02:10:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5Q9ANqg017054; Thu, 26 Jun 2008 02:10:24 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3200M09C5C9500@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 02:10:24 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3200J1WC5CA170@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 02:10:24 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5Q9AN7N001693; Thu, 26 Jun 2008 09:10:23 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-58593; Thu, 26 Jun 2008 09:10:23 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-51593151; Thu, 26 Jun 2008 09:10:22 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay4i.sun.com with ESMTP id BT-MMP-1754637; Thu, 26 Jun 2008 09:10:21 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m5Q9A6BD005597; Thu, 26 Jun 2008 11:10:07 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5Q9A6re005571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2008 11:10:06 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5Q9A6B4021404; Thu, 26 Jun 2008 11:10:06 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 11:10:06 +0200 Date: Thu, 26 Jun 2008 11:10:05 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <4862789C.1050401@Sun.COM> To: Garrett.Damore@sun.com, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, don.cragun@sun.com Message-id: <48635ced.DKaYzUHNDOasoFRi%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.582sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <4862789C.1050401@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 26 Jun 2008 09:10:06.0026 (UTC) FILETIME=[6CB462A0:01C8D76C] Status: RO Content-Length: 2135 Darren J Moffat wrote: > Garrett D'Amore wrote: > > Perhaps we can have a compile-time decision, such as done with XPG4 > > versus Sun definitions of things like strtok_r, where broken code is > > allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch. > > That doesn't solve the problem. > > > It would then be a matter of a man page update to allow developers to > > decide whether they need/want this behavior for their (broken) code. > > Developers on Linux and *BSD aren't reading Solaris man pages. The > whole reason for this case is for making building and running existing > softwar that works (regardless of what "we" think of the quality issue > of passing NULL to printf) on other platforms. > > That means no environment variables no compile time flags, nothing. > Just make our libc printf(3C) family not cause a SEGV like everyone > elses, and do it all the time. Applications from AT&T SYSvr3 typically did dump core on SunOS-4.x because they made the assumption that you may access data at address NULL and that NULL points to "". For this reason many SYSvr3 programs did dump core on SunOS-4.x when they were still parsing the command line while trying to access argv[argc]. If you really like to introduce changes that prevent NULL string pointers from dumping the core in badly written programs, then you will start to change strcmp(),.... in the next run. Is this really what we like to see on OpenSolaris? My private printf implementation prints "(NULL POINTER)" for NULL string pointers. I am not against this specific change but we should have a plan on what we like to achive with OpenSolaris and why/how we do things. If the reason for the change is just buggy software, then rather collect the core dumps from this software and send stack traces to the authors. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 26 02:18:31 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 m5Q9IUkO011235 for ; Thu, 26 Jun 2008 02:18:31 -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 m5Q9INnS018229; Thu, 26 Jun 2008 10:18:26 +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 <0K3200B0HCIOT700@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 03:18:24 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K32009I8CIOJV10@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 03:18:24 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5Q8Yvrx007684; Thu, 26 Jun 2008 09:18:24 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay23i.sun.com with ESMTP id BT-MMP-944688; Thu, 26 Jun 2008 09:18:24 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-51773651; Thu, 26 Jun 2008 09:18:22 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay24i.sun.com with ESMTP id BT-MMP-16355953; Thu, 26 Jun 2008 09:18:22 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw24] (8.14.2+/8.14.2) with ESMTP id m5Q9IJwv004605; Thu, 26 Jun 2008 11:18:19 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5Q9IJGd004599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2008 11:18:19 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5Q9IJHC021779; Thu, 26 Jun 2008 11:18:19 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 11:18:19 +0200 Date: Thu, 26 Jun 2008 11:18:18 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <20080625170838.GT2735@Sun.COM> To: Nicolas.Williams@sun.com, Garrett.Damore@sun.com Cc: PSARC-ext@sun.com, James.D.Carlson@sun.com, don.cragun@sun.com Message-id: <48635eda.R4N3qN+drmXMVIZ7%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.303sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806251546.m5PFkO6E012604@spartan.eng.sun.com> <48627047.3050100@sun.com> <18530.29344.707553.75030@gargle.gargle.HOWL> <486274DB.802@sun.com> <20080625170838.GT2735@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 26 Jun 2008 09:18:19.0039 (UTC) FILETIME=[929032F0:01C8D76D] Status: RO Content-Length: 724 Nicolas Williams wrote: > On Wed, Jun 25, 2008 at 09:39:55AM -0700, Garrett D'Amore wrote: > > Is the next step really to start checking for null arguments to other > > string functions? What about null pointers passed to other library > > routines, such as free(), qsort(), bsearch()? > > free(NULL) is already allowed, always. There is a difference: free(NULL) is a mandatory POSIX feature. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Thu Jun 26 03:10:21 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QAALo9012305 for ; Thu, 26 Jun 2008 03:10:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5QAAI6h001048; Thu, 26 Jun 2008 03:10:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K320011FEX7VC00@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 03:10:19 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3200J71EX4A6D0@nwk-avmta-2.sfbay.sun.com>; Thu, 26 Jun 2008 03:10:17 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5QAAG9Y022599; Thu, 26 Jun 2008 10:10:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3200301EGZP200@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 26 Jun 2008 11:10:16 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3200JVIEWRAR90@fe-emea-10.sun.com>; Thu, 26 Jun 2008 11:10:04 +0100 (BST) Date: Thu, 26 Jun 2008 11:10:03 +0100 From: Darren J Moffat Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <4862BEA2.8050606@sun.com> Sender: Darren.Moffat@sun.com To: Joseph Kowalski Cc: Glenn Skinner , PSARC-ext@sun.com, Jyri.Virkki@sun.com, darrenm@sac.sfbay.sun.com Message-id: <48636AFB.10607@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 458 Joseph Kowalski wrote: > Darren (several timezones removed), > > When you get through this tread, I need your position (as submitter) on > the proposed binding of Patch. From there, I can decide what to do with > this case. Patch was on purpose because while I have no intention of backporting this to Solaris 10 I see only goodness in allowing it. However I could be convinced to restrict the binding to be Minor but not Major. -- Darren J Moffat From jek3@sun.com Fri Jun 27 13:04:53 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5RK4qF4011795 for ; Fri, 27 Jun 2008 13:04:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5RK4ob5011109; Fri, 27 Jun 2008 14:04:50 -0600 (MDT) 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 <0K3500803142I600@brm-avmta-1.central.sun.com>; Fri, 27 Jun 2008 14:04:50 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K35004OK141YD20@brm-avmta-1.central.sun.com>; Fri, 27 Jun 2008 14:04:50 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5RK4m0E989261; Fri, 27 Jun 2008 13:04:49 -0700 (PDT) Date: Fri, 27 Jun 2008 10:08:06 -1000 From: Joseph Kowalski Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <48636AFB.10607@Sun.COM> To: Darren J Moffat Cc: Glenn Skinner , PSARC-ext@sun.com, Jyri.Virkki@sun.com, darrenm@sac.sfbay.sun.com Message-id: <486548A6.7050506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1425 Darren J Moffat wrote: > Joseph Kowalski wrote: >> Darren (several timezones removed), >> >> When you get through this tread, I need your position (as submitter) >> on the proposed binding of Patch. From there, I can decide what to >> do with this case. > > Patch was on purpose because while I have no intention of backporting > this to Solaris 10 I see only goodness in allowing it. > > However I could be convinced to restrict the binding to be Minor but > not Major. Please, change the release binding to Minor. Not to be heavy handed, but I will immediately derail this at a Patch binding. (For all you OpenSolaris folk, the only difference is not allowing this to be backported to Solaris 10.) Also, since there isn't a meeting on 7/2 (and the 4th for us yanks), please extend th time-out to 7/9. I can't tell people what to discuss, but there seems to be a universal opinion among the voting members that this is a black and white choice - It's the SVr4 way, or the BSD way. I'd suggest folk restrict comments to the black and white issues and avoid doing any invention (in the forum). - thanks - As for myself, I want to take another shot convincing others that this can cause incompatible failures. If I fail on that, I'll still probably derail this, but by that time, it will probably not require additional discussion and I'll just be writing an opinion to capture the rationale. - jek3 From Darren.Moffat@sun.com Mon Jun 30 02:10:27 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 m5U9AQjw006037 for ; Mon, 30 Jun 2008 02:10:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5U9ALYP004982; Mon, 30 Jun 2008 10:10:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3900601QTB2L00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Jun 2008 02:10:23 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K39007J2QT9X170@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Jun 2008 02:10:22 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5U9ALBe023084; Mon, 30 Jun 2008 09:10:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3900D01QI32O00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 30 Jun 2008 10:10:21 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K39000GEQT7FMA0@fe-emea-10.sun.com>; Mon, 30 Jun 2008 10:10:20 +0100 (BST) Date: Mon, 30 Jun 2008 10:10:19 +0100 From: Darren J Moffat Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <486548A6.7050506@sun.com> Sender: Darren.Moffat@sun.com To: Joseph Kowalski Cc: Glenn Skinner , PSARC-ext@sun.com, Jyri.Virkki@sun.com, darrenm@sac.sfbay.sun.com Message-id: <4868A2FB.8020200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 919 Joseph Kowalski wrote: > Darren J Moffat wrote: >> Joseph Kowalski wrote: >>> Darren (several timezones removed), >>> >>> When you get through this tread, I need your position (as submitter) >>> on the proposed binding of Patch. From there, I can decide what to >>> do with this case. >> >> Patch was on purpose because while I have no intention of backporting >> this to Solaris 10 I see only goodness in allowing it. >> >> However I could be convinced to restrict the binding to be Minor but >> not Major. > > Please, change the release binding to Minor. Not to be heavy handed, > but I will immediately derail this at a Patch binding. (For all you > OpenSolaris folk, the only difference is not allowing this to be > backported to Solaris 10.) Okay consider it done. > Also, since there isn't a meeting on 7/2 (and the 4th for us yanks), > please extend th time-out to 7/9. Done. -- Darren J Moffat From darrenm@opensolaris.org Mon Jun 30 02:15:22 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 m5U9FLOO006640 for ; Mon, 30 Jun 2008 02:15:21 -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 m5U9FCIu006834 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 30 Jun 2008 10:15:20 +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 <0K3900L0FR1JZU00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 30 Jun 2008 03:15:19 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3900CB5R1HL080@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 30 Jun 2008 03:15:18 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5U9FHqo024055 for ; Mon, 30 Jun 2008 09:15:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3900D01QI32O00@fe-emea-10.sun.com> (original mail from darrenm@opensolaris.org) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 30 Jun 2008 10:15:17 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K39000TFR12FMA0@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 30 Jun 2008 10:15:04 +0100 (BST) Date: Mon, 30 Jun 2008 10:15:02 +0100 From: Darren J Moffat Subject: Re: libc printf behaviour for NULL string [PSARC/2008/403 FastTrack timeout 07/02/2008] In-reply-to: <15094613.1214679825325.JavaMail.Twebapp@oss-app1> Sender: Darren.Moffat@sun.com To: "Richard L. Hamilton" Cc: PSARC-ext@sun.com Message-id: <4868A416.1050805@opensolaris.org> Organization: OpenSolaris MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <15094613.1214679825325.JavaMail.Twebapp@oss-app1> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 599 Richard L. Hamilton wrote: > Encouraging discrepancies between standards and code to be perpetuated devalues the > standards, without which all is chaos. The current beahviour of crash and the proposed behaviour to follow glibc and *BSD are both perfectly compliant with the standard. The standard doesn't define what happens so either is acceptable. It isn't the developers we are punishing by not implementing this case, many of them don't are anyway, but we are hurting adoption of OpenSolaris and making it difficult to impossible to run some critical applications. -- Darren J Moffat From jek3@sun.com Mon Jun 30 16:56:43 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 m5UNug3D002198 for ; Mon, 30 Jun 2008 16:56:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5UNucT0014346; Tue, 1 Jul 2008 00:56:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3A00H0RVUEGX00@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Jun 2008 16:56:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3A004A4VUE20C0@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Jun 2008 16:56:38 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5UNuWQK793180; Mon, 30 Jun 2008 16:56:37 -0700 (PDT) Date: Mon, 30 Jun 2008 13:59:57 -1000 From: Joseph Kowalski Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <4868A2FB.8020200@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4869737D.5000204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> <4868A2FB.8020200@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 3467 First, the ARCs were created to address multiple issues. The two overriding ones were: 1) Make sure multiple products (eventually consolidations) "played nice". 2) Be the guardians of compatibility. Obviously, these are very interrelated. (Historical note: I believe this was the initial ordering, but the priorities seem to have reversed.) We focus on well defined interfaces because that is the best tool we have to serve the higher level needs. We can make fairly automated changes when a specific, well defined interface can be cited. When there isn't such an interface, then evaluation of compatibility becomes more difficult. Just because a behavior isn't well specified, doesn't mean its not a compatibility issue. In this case, we seem to clearly have a compatibility issue of controversial magnitude. It does exist, because one could easily contrive an existence proof. The question is all about the "magnitude". It seems to be widely asserted that the compatibility exposure is negligible. Let me counter that by citing a instance that was relayed to me (second hand). Circa 2000, I was the technical lead for the "whitesmoke" project. The details are "Sun Private", but all that need to be said is that Sun was working with a large customer with a very widely distributed, high availability product. This story is from my counterpart in this corporate relationship. He was relaying this story in the context of "we don't change any components - only fully tested aggregations". His story was one of a function SEVg'ing in response to a rare case of inputs. The module which died, was quickly restarted by a "heartbeat" deamon and all was well - an outage measured in seconds. The object was upgraded. The function in question was modified to respond to this rare case with inputs to respond with an error code. It was a valid error code, but it turned out that there was a second bug in the consumer of the output of the initial module. The result was an infinite exchange of messages between the two objects, and not real computational progress was made. The result was an outage of several days (mostly to diagnose the problem). This very similar to this proposal, except that we have an even more significant change. The story is one of "SEVG -> error return". This case proposes "SEVG -> success return". The motivation for this proposal seems to be "Linux familiarity". The "program" around "Linux familiarity", is all about development tools, the utility set and additional components. It is explicitly not about changes to the programmatic interfaces. So, what I believe we have here is a non-negligible incompatibility in the programmatic interfaces weighted against a perception of "familiarity" in an area where "familiarity" isn't a goal. Hence, we should not make this change. I should point out (because if I don't, I'm sure that somebody will), there have been numerous cases which proposed adding additional error codes. The points to notice are: 1) Always in a Minor release (but we've already dealt with that) 2) Only when we had to, as in a standard required it or overloading an existing error code couldn't be overloaded. In other words, it was necessary for the application to react differently. We always made these changes carefully. So, that is my argument against making this change. I'm sure your mileage will vary. - jek3 From bart.smaalders@sun.com Mon Jun 30 17:45:37 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 m610jaOI003448 for ; Mon, 30 Jun 2008 17:45:36 -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 m610jVdT001978; Tue, 1 Jul 2008 01:45:33 +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 <0K3A00007Y3UHV00@brm-avmta-1.central.sun.com>; Mon, 30 Jun 2008 18:45:30 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3A0005YY3U7G00@brm-avmta-1.central.sun.com>; Mon, 30 Jun 2008 18:45:30 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m610jUQh020738; Tue, 01 Jul 2008 00:45:30 +0000 (GMT) Date: Mon, 30 Jun 2008 17:45:29 -0700 From: Bart Smaalders Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <4869737D.5000204@sun.com> To: Joseph Kowalski Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <48697E29.6090103@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> <4868A2FB.8020200@Sun.COM> <4869737D.5000204@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 2316 Joseph Kowalski wrote: ... > His > story was one of a function SEVg'ing in response to a rare case of > inputs. The module which died, was quickly restarted by a "heartbeat" > deamon and all was well - an outage measured in seconds. The object was > upgraded. The function in question was modified to respond to this rare > case with inputs to respond with an error code. It was a valid error > code, but it turned out that there was a second bug in the consumer of > the output of the initial module. The result was an infinite exchange > of messages between the two objects, and not real computational progress > was made. The result was an outage of several days (mostly to diagnose > the problem). ... > I should point out (because if I don't, I'm sure that somebody will), > there have been numerous cases which proposed adding additional error > codes. The points to notice are: > > 1) Always in a Minor release (but we've already dealt with that) > > 2) Only when we had to, as in a standard required it or overloading > an existing error code couldn't be overloaded. In other words, it > was necessary for the application to react differently. We always > made these changes carefully. > > So, that is my argument against making this change. I'm sure your > mileage will vary. Note that exactly the same argument can be made for any bug fix; what this argues for is virtually complete stasis, since any change we make can and will cause problems for broken applications. Indeed, we've seen exactly the same problem with a library that used to dereference a user-supplied pointer, and then later this functionality was done in the kernel. What had been a SEGV was turned into a EFAULT, and the application misbehaved in a new way. I don't think requiring all previously broken programs to fail in exactly the same manner across all update releases of Solaris 10 is a reasonable standard, and is certainly not one that we follow. Jim already pointed out that the introduction of new options for existing commands would cause the same sorts of problems. Adding new codes to an ioctl would as well. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From jek3@sun.com Mon Jun 30 19:30:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m612UNJP006642 for ; Mon, 30 Jun 2008 19:30:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m612ULux045469; Mon, 30 Jun 2008 20:30:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3B002012YL1N00@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Jun 2008 19:30:21 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3B00KMN2YL5070@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Jun 2008 19:30:21 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m612UKh7809290; Mon, 30 Jun 2008 19:30:20 -0700 (PDT) Date: Mon, 30 Jun 2008 16:33:45 -1000 From: Joseph Kowalski Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <48697E29.6090103@Sun.COM> To: Bart Smaalders Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <48699789.2090400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> <4868A2FB.8020200@Sun.COM> <4869737D.5000204@sun.com> <48697E29.6090103@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2060 Bart Smaalders wrote: > Note that exactly the same argument can be made for any bug fix; > what this argues for is virtually complete stasis, since any change > we make can and will cause problems for broken applications. Its quite easy to label an application as "broken" after it fails subject to a change in environment or simply a new test. To one degree or another, greater that 99.44% of applications are broken. Its a real world we live in. > Indeed, we've seen exactly the same problem with a library that used > to dereference a user-supplied pointer, and then later this functionality > was done in the kernel. What had been a SEGV was turned into a > EFAULT, and the application misbehaved in a new way. OK. I now have been given two appropriate stories to tell. I felt I needed to address some assertions on the mail-trail about "can't cause a failure". If everyone can accept that it can happen, we can shorten the discussion about "how significant" or "how often" to simply the risk/benefit discussion. > I don't think requiring all previously broken programs to fail in exactly > the same manner across all update releases of Solaris 10 is a reasonable > standard, and is certainly not one that we follow. Jim already > pointed out > that the introduction of new options for existing commands would cause > the same sorts of problems. Adding new codes to an ioctl would as well. Exactly. (Well, update/minor, but we are past that.) Its all about risk/benefit. Taking such risks for "familiarity" in an area where we are not instructed to strive for "familiarity" seems like a very poor bet. (As for Jim's example, this is an area where we are instructed to strive for "familiarity". That changes the ratio.) For some reason "stasis" seems to be a harsh word, but it is exactly appropriate. Taking no risks for significant benefit is wrong. Just the same, taking risks for only negligible benefit is also wrong. I'm only asserting that we should evaluate this careful - hopefully objectively. > - Bart - jek3 From Darren.Moffat@sun.com Tue Jul 1 03:10:31 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m61AAV6s018292 for ; Tue, 1 Jul 2008 03:10:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m61AAU7W024168 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Jul 2008 03:10:31 -0700 (PDT) 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 <0K3B00207O9IBY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Jul 2008 04:10:30 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3B007JJO9H3DC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Jul 2008 04:10:30 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m61AATfb027858 for ; Tue, 01 Jul 2008 10:10:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3B00E01NYPXK00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Jul 2008 11:10:29 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3B009N5O999360@fe-emea-10.sun.com>; Tue, 01 Jul 2008 11:10:22 +0100 (BST) Date: Tue, 01 Jul 2008 11:10:21 +0100 From: Darren J Moffat Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <48699789.2090400@sun.com> Sender: Darren.Moffat@sun.com To: Joseph Kowalski Cc: Bart Smaalders , PSARC-ext@sun.com Message-id: <486A028D.9070809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> <4868A2FB.8020200@Sun.COM> <4869737D.5000204@sun.com> <48697E29.6090103@Sun.COM> <48699789.2090400@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 927 Let me set the record straight on the motivation for this case. It is NOT about "Linux familiarity" even though the GNU libc is used as part of the rationale. I also used BSD and others pointed out the similar (but not identical) behaviour on AIX and HP-UX. Basically we are different from everyone else (not Linux but everyone else that matters) and it hurts us. So please don't put this case into the "Linux familiarity" bucket that isn't why I'm doing this. This case is about returning to the original SunOS 4.x/BSD behaviour for printf(3C) family. The reason for doing so is the huge volume of software out there that we want to run on OpenSolaris based distributions that assumes that behaviour. It might seem like I'm nitpikcing but I've been thinking about running this case for about 8 years now, long before OpenSolaris became real and before the current big "familiarity" push. -- Darren J Moffat From Darren.Reed@sun.com Thu Jul 3 13:51:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m63Kpt30025615 for ; Thu, 3 Jul 2008 13:51:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m63KpkSS026883 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Jul 2008 04:51:54 +0800 (SGT) 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 <0K3G00L017AFDN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Jul 2008 14:51:51 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3G00G897AE7Q20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Jul 2008 14:51:51 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m63KpoCg000813 for ; Thu, 03 Jul 2008 20:51:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3G00H0179M7J00@fe-emea-10.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Jul 2008 21:51:50 +0100 (BST) Received: from [129.146.106.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3G000W17ACYJ60@fe-emea-10.sun.com>; Thu, 03 Jul 2008 21:51:50 +0100 (BST) Date: Thu, 03 Jul 2008 13:51:48 -0700 From: Darren Reed Subject: Re: 2008/403 [libc printf behaviour for NULL string] In-reply-to: <486A028D.9070809@Sun.COM> Sender: Darren.Reed@sun.com To: Darren J Moffat Cc: Joseph Kowalski , Bart Smaalders , PSARC-ext@sun.com Message-id: <486D3BE4.405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <200806252101.m5PL149a015108@ivrel.sfbay.sun.com> <4862BEA2.8050606@sun.com> <48636AFB.10607@Sun.COM> <486548A6.7050506@sun.com> <4868A2FB.8020200@Sun.COM> <4869737D.5000204@sun.com> <48697E29.6090103@Sun.COM> <48699789.2090400@sun.com> <486A028D.9070809@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1164 Darren J Moffat wrote: > Let me set the record straight on the motivation for this case. > > It is NOT about "Linux familiarity" even though the GNU libc is used > as part of the rationale. I also used BSD and others pointed out the > similar (but not identical) behaviour on AIX and HP-UX. Basically we > are different from everyone else (not Linux but everyone else that > matters) and it hurts us. So please don't put this case into the > "Linux familiarity" bucket that isn't why I'm doing this. > > This case is about returning to the original SunOS 4.x/BSD behaviour > for printf(3C) family. The reason for doing so is the huge volume of > software out there that we want to run on OpenSolaris based > distributions that assumes that behaviour. > > It might seem like I'm nitpikcing but I've been thinking about running > this case for about 8 years now, long before OpenSolaris became real > and before the current big "familiarity" push. It would seem that "%s" can result in "" inside the kernel with cmn_err(), at the very least, so libc printing something is not inconceivable.... See: $SRC/common/util/string.c Darren From Darren.Moffat@Sun.COM Thu Jul 10 02:50:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6A9oglH018748 for ; Thu, 10 Jul 2008 02:50:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6A9ogi4019709 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 10 Jul 2008 02:50:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3S00B07BCI4T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 10 Jul 2008 02:50:42 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3S00410BCGF0D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 10 Jul 2008 02:50:41 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6A9oe5J002452 for ; Thu, 10 Jul 2008 09:50:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3S00401B8ZT800@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 10 Jul 2008 10:50:40 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3S00KFZBCC5C40@fe-emea-10.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 10 Jul 2008 10:50:36 +0100 (BST) Date: Thu, 10 Jul 2008 10:50:36 +0100 From: Darren J Moffat Subject: PSARC/2008/403 libc printf behaviour for NULL string (Derailed & Approved) Sender: Darren.Moffat@Sun.COM To: PSARC-EXT@Sun.COM Message-id: <4875DB6C.2060301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 222 This case was derailed in PSARC by Joe Kowalski (jek3). It was voted on and had a majority "approve" vote. Joe will be writing an opinion document. I've marked the status to: waiting need opinion. -- Darren J Moffat From Darren.Moffat@sun.com Tue Jun 23 02:07:57 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5N97u98018375 for ; Tue, 23 Jun 2009 02:07:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5N97sML023383 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 23 Jun 2009 02:07:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLO00807PD7Z000@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jun 2009 02:07:55 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLO00BZNPD6W4E0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jun 2009 02:07:55 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5N97sGV006849 for ; Tue, 23 Jun 2009 09:07:54 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLO00D00O3MF100@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jun 2009 10:07:54 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLO00F6VPCLV6E0@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 23 Jun 2009 10:07:34 +0100 (BST) Date: Tue, 23 Jun 2009 10:07:33 +0100 From: Darren J Moffat Subject: PSARC/2008/403 Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Message-id: <4A409B55.6020001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 629 This case was derailed and voted on 09 Jul 2008. The was a vote and the majority voted to approve with one deny. Normally what happens is that the minority voters provide opinion text. Due to extraordinary circumstances this is not possible in this case. The effective text of what would have been in the opinion is in the case log for the member that derailed and subsequently voted deny. This course of action has been discussed with other ARC members but I had delayed in putting it in place, I'm doing so now. Given the above this case is closed approved fast-track effective 09 Jul 2008. -- Darren J Moffat