From sacadmin Thu Nov 30 00:19:37 2006 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAU8Jb2a010559; Thu, 30 Nov 2006 00:19:37 -0800 (PST) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id kAU8JbR6010555; Thu, 30 Nov 2006 00:19:37 -0800 (PST) Date: Thu, 30 Nov 2006 00:19:37 -0800 (PST) From: Darren Reed Message-Id: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Subject: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] Status: RO Content-Length: 7374 Subject: PSARC FastTrack [12/07/2006]: Make err/warn part of Solaris's libc Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Make err/warn part of Solaris's libc 1.2. Name of Document Author/Supplier: Author: Darren Reed 1.3 Date of This Document: 30 November, 2006 4. Technical Description Summary ======= As part of the BSD4.4 effort to re-implement many of the common shell commands, a common error and warning message interface was introduced. A few subsystems within Solaris have used private implementations of this exact interface with success; given its general utility both for BSD and within Solaris, we propose to add this interface to Solaris's libc as a Committed interface. Patch binding is desired. Details ======= The err() and warn() families of functions have their origins in the release of 4.4BSD and have been a part of all open source BSD releases since that time. The err() and warn() families of functions provide an easy to use interface for emitting an error message via stderr. The both the err-family and warn-family of functions are used to print out a message to stderr. In addition the err-family functions are passed an exit code, and terminate the process by invoking exit(3C) after printing the message. If a NULL format string is supplied, only the program name is displayed on stderr. If a format string is supplied, the program name is immediately followed by ": " and is prepended to the format string on output. err(), verr(), warn() and vwarn() all append ": " followed by a system error string, equivalent to that returned by strerror(3c), to the formatted output string. The 'x' variants of these functions do not append either the ": " or the system error string. Analogous to the vprintf family of functions, the 'v' variants of these functions take a va_list parameter, permitting them to be used for building special case functions using varargs. All strings output are terminated with a newline character. The list of functions to being proposed for elevation to "Committed" is: void err(int, const char *, ...); void verr(int, const char *, va_list); void errx(int, const char *, ...); void verrx(int, const char *, va_list); void warn(const char *, ...); void vwarn(const char *, va_list); void warnx(const char *, ...); void vwarnx(const char *, va_list); Examples -------- int fd = open("/nobodyhome", O_RDONLY); warn(NULL); a.out: No such file or directory warn("open"); a.out: open: No such file or directory warn("open(%s,O_RDONLY)", "/nobodyhome"); a.out: open(/nobodyhome,O_RDONLY): No such file or directory warnx(NULL); a.out warnx("open"); a.out: open Copyright --------- While these functions originally appeared in 4.4BSD, they have been clean-room written and thus our code is not required to carry any non-Sun copyright. The manual page included comes from NetBSD 3.0. Interface table =============== +-----------+-------------+-------------------------------+ | Interface | Commitment | Description | +-----------+-------------+-------------------------------+ | | Committed | Header file for new functions | | err | Committed | | | verr | Committed | | | errx | Committed | | | verrx | Committed | | | warn | Committed | | | vwarn | Committed | | | warnx | Committed | | | vwarnx | Committed | | +-----------+-------------+-------------------------------+ ============================================================================= Standard C Library Functions err(3C) NAME err, verr, errx, verrx, warn, vwarn, warnx, vwarnx -- formatted error messages LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include void err(int status, const char *fmt, ...); void verr(int status, const char *fmt, va_list args); void errx(int status, const char *fmt, ...); void verrx(int status, const char *fmt, va_list args); void warn(const char *fmt, ...); void vwarn(const char *fmt, va_list args); void warnx(const char *fmt, ...); void vwarnx(const char *fmt, va_list args); DESCRIPTION The err() and warn() family of functions display a formatted error mes- sage on the standard error output. In all cases, the last component of the program name, a colon character, and a space are output. If the fmt argument is not NULL, the formatted error message is output. In the case of the err(), verr(), warn(), and vwarn() functions, the error message string affiliated with the current value of the global variable errno is output next, preceded by a colon character and a space if fmt is not NULL. In all cases, the output is followed by a newline character. The errx(), verrx(), warnx(), and vwarnx() functions will not output this error message string. The err(), verr(), errx(), and verrx() functions do not return, but instead cause the program to terminate with the status value given by the argument status. EXAMPLES Display the current errno information string and terminate with status indicating failure: if ((p = malloc(size)) == NULL) err(EXIT_FAILURE, NULL); if ((fd = open(file_name, O_RDONLY, 0)) == -1) err(EXIT_FAILURE, "%s", file_name); Display an error message and terminate with status indicating failure: if (tm.tm_hour < START_TIME) errx(EXIT_FAILURE, "too early, wait until %s", start_time_string); Warn of an error: if ((fd = open(raw_device, O_RDONLY, 0)) == -1) warnx("%s: %s: trying the block device", raw_device, strerror(errno)); if ((fd = open(block_device, O_RDONLY, 0)) == -1) warn("%s", block_device); SEE ALSO exit(3c), getexecname(3c), strerror(3c) HISTORY The err() and warn() functions first appeared in 4.4BSD. CAVEATS It is important never to pass a string with user-supplied data as a for- mat without using `%s'. An attacker can put format specifiers in the string to mangle your stack, leading to a possible security hole. This holds true even if you have built the string ``by hand'' using a function like snprintf(), as the resulting string may still contain user-supplied conversion specifiers for later interpolation by the err() and warn() functions. Always be sure to use the proper secure idiom: err(1, "%s", string); SunOS 5.10 Last change: 30 November 2006 2 ============================================================================= 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Thu Nov 30 03:49:26 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUBnQff014024; Thu, 30 Nov 2006 03:49:26 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id kAUBnP5g012416; Thu, 30 Nov 2006 03:49:26 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUBnKal003615; Thu, 30 Nov 2006 11:49:20 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9J00C01KQE0W00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 30 Nov 2006 11:49:19 +0000 (GMT) Received: from [192.168.73.103] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9J00CH7KU6S020@d1-emea-09.sun.com>; Thu, 30 Nov 2006 11:49:19 +0000 (GMT) Date: Thu, 30 Nov 2006 11:49:18 +0000 From: Darren J Moffat Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Darren Reed Cc: PSARC@sac.sfbay.sun.com Message-id: <456EC53E.8050903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 392 Does this case modify any part of Solaris to actually use these ? I believe there has been some discussion about how to do more with FMA for software components and this might be either pre-empting that or just complentary. Is the rationale for this case to make it easier to port software that already uses them or is it one of code duplication removal in Solaris ? -- Darren J Moffat From sacadmin Thu Nov 30 04:40:27 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUCeRF4014781; Thu, 30 Nov 2006 04:40:27 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kAUChpdR008111; Thu, 30 Nov 2006 07:43:51 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kAUChpha008108; Thu, 30 Nov 2006 07:43:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17774.53767.542454.913747@gargle.gargle.HOWL> Date: Thu, 30 Nov 2006 07:43:51 -0500 From: James Carlson To: Darren J Moffat Cc: Darren Reed , PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-Reply-To: <456EC53E.8050903@Sun.COM> References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 762 Darren J Moffat writes: > Is the rationale for this case to make it easier to port software that > already uses them or is it one of code duplication removal in Solaris ? Having faced this annoyance many times, I think the "easier to port" answer would be enough. This isn't quite the same as adding the BSD daemon() function, where many users of the existing setsid() function manage to get the sequence wrong (usually missing the double fork), so I think retrofitting warn/err into the rest of the source base shouldn't be required. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Nov 30 04:42:02 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUCg2kJ014811; Thu, 30 Nov 2006 04:42:02 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUCg1L5021120; Thu, 30 Nov 2006 04:42:02 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUCfu5L010853; Thu, 30 Nov 2006 12:41:56 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9J00F01N728U00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 30 Nov 2006 12:41:56 +0000 (GMT) Received: from [192.168.73.103] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9J003RUN9VI000@d1-emea-10.sun.com>; Thu, 30 Nov 2006 12:41:56 +0000 (GMT) Date: Thu, 30 Nov 2006 12:41:55 +0000 From: Darren J Moffat Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <17774.53767.542454.913747@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Darren Reed , PSARC@sac.sfbay.sun.com Message-id: <456ED193.9010305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> <17774.53767.542454.913747@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 374 James Carlson wrote: > Darren J Moffat writes: >> Is the rationale for this case to make it easier to port software that >> already uses them or is it one of code duplication removal in Solaris ? > > Having faced this annoyance many times, I think the "easier to port" > answer would be enough. Me too, the case just didn't say why so I was curious. -- Darren J Moffat From sacadmin Thu Nov 30 04:46:50 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUCkn4Z014840; Thu, 30 Nov 2006 04:46:50 -0800 (PST) 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 kAUCkhGY009372; Thu, 30 Nov 2006 20:46:43 +0800 (SGT) 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 <0J9J00A01NHEA600@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Thu, 30 Nov 2006 20:46:43 +0800 (SGT) Received: from [129.158.87.91] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9J001OWNHUI7H7@mail-apac.sun.com>; Thu, 30 Nov 2006 20:46:43 +0800 (SGT) Date: Thu, 30 Nov 2006 21:46:04 +0800 From: Darren Reed Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <456EC53E.8050903@Sun.COM> Sender: Darren.Reed@Sun.COM To: Darren J Moffat Cc: Darren Reed , PSARC@sac.sfbay.sun.com Message-id: <456EE09C.6020004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 485 Darren J Moffat wrote: > Does this case modify any part of Solaris to actually use these ? No. > I believe there has been some discussion about how to do more with FMA > for software components and this might be either pre-empting that or > just complentary. > > Is the rationale for this case to make it easier to port software that > already uses them or is it one of code duplication removal in Solaris ? To make it easier to port software that already uses them. Darren From sacadmin Thu Nov 30 05:31:44 2006 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUDVevl015467; Thu, 30 Nov 2006 05:31:44 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.211.1]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUDVYtF022335; Thu, 30 Nov 2006 13:31:38 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUDVYUq003330; Thu, 30 Nov 2006 14:31:34 +0100 (MET) Message-Id: <200611301331.kAUDVYUq003330@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Darren J Moffat cc: James Carlson , Darren Reed , PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-Reply-To: <456ED193.9010305@Sun.COM> References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> <17774.53767.542454.913747@gargle.gargle.HOWL> <456ED193.9010305@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Nov 2006 14:31:33 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 580 >James Carlson wrote: >> Darren J Moffat writes: >>> Is the rationale for this case to make it easier to port software that >>> already uses them or is it one of code duplication removal in Solaris ? >> >> Having faced this annoyance many times, I think the "easier to port" >> answer would be enough. > >Me too, the case just didn't say why so I was curious. But I would expect the project to remove any duplication (just like I did when I added mkdtemp() to Solaris: make sure that when programs have conditional included own copies start using the new versions. Casper From sacadmin Thu Nov 30 05:47:15 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUDlEF1015789; Thu, 30 Nov 2006 05:47:15 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kAUDodZg008294; Thu, 30 Nov 2006 08:50:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kAUDodee008291; Thu, 30 Nov 2006 08:50:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17774.57774.906822.952071@gargle.gargle.HOWL> Date: Thu, 30 Nov 2006 08:50:38 -0500 From: James Carlson To: Casper.Dik@sun.com Cc: Darren J Moffat , Darren Reed , PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-Reply-To: <200611301331.kAUDVYUq003330@vaticaan.holland.sun.com> References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> <17774.53767.542454.913747@gargle.gargle.HOWL> <456ED193.9010305@Sun.COM> <200611301331.kAUDVYUq003330@vaticaan.holland.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 772 Casper.Dik@Sun.COM writes: > >Me too, the case just didn't say why so I was curious. > > > But I would expect the project to remove any duplication (just like I did > when I added mkdtemp() to Solaris: make sure that when programs have > conditional included own copies start using the new versions. I agree with that -- where there are private implementations of err()/warn(), this project should yank them out. I thought Darren was suggesting retrofitting existing fprintf(stderr, ...) calls in the source base. I think that'd be excessive. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Nov 30 05:59:55 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUDxtfE016411; Thu, 30 Nov 2006 05:59:55 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUDxsxA008494; Thu, 30 Nov 2006 05:59:55 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUDxnvM000351; Thu, 30 Nov 2006 13:59:49 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9J00601QRDDA00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 30 Nov 2006 13:59:49 +0000 (GMT) Received: from [192.168.73.103] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9J00CFFQVOS030@d1-emea-09.sun.com>; Thu, 30 Nov 2006 13:59:49 +0000 (GMT) Date: Thu, 30 Nov 2006 13:59:48 +0000 From: Darren J Moffat Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <17774.57774.906822.952071@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Casper.Dik@Sun.COM, Darren Reed , PSARC@sac.sfbay.sun.com Message-id: <456EE3D4.3040401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> <17774.53767.542454.913747@gargle.gargle.HOWL> <456ED193.9010305@Sun.COM> <200611301331.kAUDVYUq003330@vaticaan.holland.sun.com> <17774.57774.906822.952071@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 767 James Carlson wrote: > Casper.Dik@Sun.COM writes: >>> Me too, the case just didn't say why so I was curious. >> >> But I would expect the project to remove any duplication (just like I did >> when I added mkdtemp() to Solaris: make sure that when programs have >> conditional included own copies start using the new versions. > > I agree with that -- where there are private implementations of > err()/warn(), this project should yank them out. > > I thought Darren was suggesting retrofitting existing fprintf(stderr, > ...) calls in the source base. I think that'd be excessive. What I was doing was first trying to work out the motivation and if there were any initial consumers. Casper and Jim have already said were I was going next. -- Darren J Moffat From sacadmin Thu Nov 30 10:09:23 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUI9Nel022500; Thu, 30 Nov 2006 10:09:23 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAUI8nXE016196; Thu, 30 Nov 2006 10:08:49 -0800 (PST) Message-Id: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> Date: Thu, 30 Nov 2006 10:08:49 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2006/662 [add err/warn to libc] To: PSARC@sac.sfbay.sun.com, dr146992@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yWA529LcyctrV6pUJAEGXw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 661 Date: Thu, 30 Nov 2006 00:19:37 -0800 (PST) From: Darren Reed Subject: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] ... Details ... If a NULL format string is supplied, only the program name is displayed on stderr. If a format string is supplied, the program name is immediately followed by ": " and is prepended to the format string on output. How is the program name determined? By consulting argv[0]? What happens if that string has been changed from its original value? (Please make the spec more precise by including this information.) -- Glenn From sacadmin Thu Nov 30 11:50:53 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUJoqOY026739; Thu, 30 Nov 2006 11:50:53 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kAUJokkG589195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Nov 2006 11:50:46 -0800 (PST) Received: (from tpm@localhost) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id kAUJokPg589194; Thu, 30 Nov 2006 11:50:46 -0800 (PST) Date: Thu, 30 Nov 2006 11:50:45 -0800 From: Tim Marsland To: Glenn Skinner Cc: PSARC@sac.sfbay.sun.com, dr146992@sac.sfbay.sun.com Subject: Re: 2006/662 [add err/warn to libc] Message-ID: <20061130195045.GD569793@eng.sun.com> Reply-To: Tim Marsland References: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> User-Agent: Mutt/1.4.2.1i Organization: Software; Sun Microsystems, Inc. Status: RO Content-Length: 544 * Glenn Skinner [2006-11-30 10:11]: > > ... > If a NULL format string is supplied, only the program name is > displayed on stderr. If a format string is supplied, the program > name is immediately followed by ": " and is prepended to the > format string on output. > > How is the program name determined? By consulting argv[0]? What > happens if that string has been changed from its original value? Perhaps it should get the name from /proc//psinfo - i.e. like syslog(3c) does. tim From sacadmin Thu Nov 30 12:34:13 2006 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUKYCNt028056; Thu, 30 Nov 2006 12:34:13 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.212.1]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUKY7xZ029597; Thu, 30 Nov 2006 20:34:07 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUKY70F027333; Thu, 30 Nov 2006 21:34:07 +0100 (MET) Message-Id: <200611302034.kAUKY70F027333@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Tim Marsland cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, dr146992@sac.sfbay.sun.com Subject: Re: 2006/662 [add err/warn to libc] In-Reply-To: <20061130195045.GD569793@eng.sun.com> References: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> <20061130195045.GD569793@eng.sun.com> Date: Thu, 30 Nov 2006 21:34:07 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 772 >* Glenn Skinner [2006-11-30 10:11]: >> >> ... >> If a NULL format string is supplied, only the program name is >> displayed on stderr. If a format string is supplied, the program >> name is immediately followed by ": " and is prepended to the >> format string on output. >> >> How is the program name determined? By consulting argv[0]? What >> happens if that string has been changed from its original value? > >Perhaps it should get the name from /proc//psinfo - i.e. >like syslog(3c) does. That's what I assumed it would do; clearly argv[0] is not easily obtained. Or, perhaps, getexecname()? (The code in syslog() predates getexecname(); which would be more useful? They're generally the same... Casper From sacadmin Thu Nov 30 12:53:40 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUKrd5r028396; Thu, 30 Nov 2006 12:53:39 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAUKr64R017293; Thu, 30 Nov 2006 12:53:06 -0800 (PST) Message-Id: <200611302053.kAUKr64R017293@ivrel.sfbay.sun.com> Date: Thu, 30 Nov 2006 12:53:06 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2006/662 [add err/warn to libc] To: PSARC@sac.sfbay.sun.com Cc: dr146992@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Tdk+sV3tJ+r1ctgCIPCdJw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1196 From: Casper.Dik@sun.com Subject: Re: 2006/662 [add err/warn to libc] Date: Thu, 30 Nov 2006 21:34:07 +0100 >* Glenn Skinner [2006-11-30 10:11]: >> >> ... >> If a NULL format string is supplied, only the program name is >> displayed on stderr. If a format string is supplied, the program >> name is immediately followed by ": " and is prepended to the >> format string on output. >> >> How is the program name determined? By consulting argv[0]? What >> happens if that string has been changed from its original value? > >Perhaps it should get the name from /proc//psinfo - i.e. >like syslog(3c) does. That's what I assumed it would do; clearly argv[0] is not easily obtained. Right. I wasn't completely awake when I sent my original question. Or, perhaps, getexecname()? (The code in syslog() predates getexecname(); which would be more useful? They're generally the same... Mostly, I just want to ensure that the documentation says where/how the program name is obtained. Either of psinfo or getexecname() would be fine with me. -- Glenn From sacadmin Thu Nov 30 19:22:02 2006 Received: from sineb-mail-3.sun.com ([192.18.19.10]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB13M0jg007969 for ; Thu, 30 Nov 2006 19:22:01 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB13Lt1T019490 for ; Fri, 1 Dec 2006 11:21:55 +0800 (SGT) 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 <0J9K00301RYG8P00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Fri, 01 Dec 2006 11:21:55 +0800 (SGT) Received: from [129.158.87.91] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9K009FJS0G7BBB@mail-apac.sun.com>; Fri, 01 Dec 2006 11:21:53 +0800 (SGT) Date: Fri, 01 Dec 2006 12:21:11 +0800 From: Darren Reed Subject: Re: 2006/662 [add err/warn to libc] In-reply-to: <200611302053.kAUKr64R017293@ivrel.sfbay.sun.com> Sender: Darren.Reed@Sun.COM To: Glenn Skinner Cc: PSARC@sac.sfbay.sun.com Message-id: <456FADB7.8010203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200611302053.kAUKr64R017293@ivrel.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1274 Glenn Skinner wrote: > From: Casper.Dik@sun.com > Subject: Re: 2006/662 [add err/warn to libc] > Date: Thu, 30 Nov 2006 21:34:07 +0100 > > >* Glenn Skinner [2006-11-30 10:11]: > >> > >> ... > >> If a NULL format string is supplied, only the program name is > >> displayed on stderr. If a format string is supplied, the program > >> name is immediately followed by ": " and is prepended to the > >> format string on output. > >> > >> How is the program name determined? By consulting argv[0]? What > >> happens if that string has been changed from its original value? > > > >Perhaps it should get the name from /proc//psinfo - i.e. > >like syslog(3c) does. > > That's what I assumed it would do; clearly argv[0] is not easily > obtained. > >Right. I wasn't completely awake when I sent my original question. > > Or, perhaps, getexecname()? (The code in syslog() predates > getexecname(); which would be more useful? They're generally the > same... > >Mostly, I just want to ensure that the documentation says where/how the >program name is obtained. Either of psinfo or getexecname() would be >fine with me. > > getexecname() is used. Darren From sacadmin Thu Nov 30 20:36:23 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB14aMK8008874 for ; Thu, 30 Nov 2006 20:36:23 -0800 (PST) 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 kB14aGd5007593 for ; Fri, 1 Dec 2006 12:36:16 +0800 (SGT) 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 <0J9K00L01VF01F00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Fri, 01 Dec 2006 12:36:16 +0800 (SGT) Received: from [129.158.87.91] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9K001X3VGGRZ74@mail-apac.sun.com>; Fri, 01 Dec 2006 12:36:16 +0800 (SGT) Date: Fri, 01 Dec 2006 13:35:35 +0800 From: Darren Reed Subject: Re: 2006/662 [add err/warn to libc] In-reply-to: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> Sender: Darren.Reed@Sun.COM To: Glenn Skinner Cc: PSARC@sac.sfbay.sun.com Message-id: <456FBF27.1080404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200611301808.kAUI8nXE016196@ivrel.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 920 Glenn Skinner wrote: > Date: Thu, 30 Nov 2006 00:19:37 -0800 (PST) > From: Darren Reed > Subject: Make err/warn part of Solaris's libc [PSARC/2006/662 > Timeout: 12/07/2006] > > ... > Details > > ... > If a NULL format string is supplied, only the program name is > displayed on stderr. If a format string is supplied, the program > name is immediately followed by ": " and is prepended to the > format string on output. > >How is the program name determined? By consulting argv[0]? What >happens if that string has been changed from its original value? > >(Please make the spec more precise by including this information.) > The man page attached with the case materials does include a reference to getexecname(3c) in the "SEE ALSO" section for this purpose but I will additionally update the spec to discuss how the program name is determined. Darren From sacadmin Mon Dec 4 04:42:15 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB4CgEui015400 for ; Mon, 4 Dec 2006 04:42:15 -0800 (PST) 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 kB4Cg8aV008464 for ; Mon, 4 Dec 2006 20:42:09 +0800 (SGT) 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 <0J9R00B011Q9OR00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 04 Dec 2006 20:42:08 +0800 (SGT) Received: from [129.158.87.227] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9R001FR1Y7S2LS@mail-apac.sun.com> for PSARC@sac.sfbay.sun.com; Mon, 04 Dec 2006 20:42:08 +0800 (SGT) Date: Tue, 05 Dec 2006 00:41:25 +1100 From: Darren Reed Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> Sender: Darren.Reed@Sun.COM To: PSARC@sac.sfbay.sun.com Message-id: <45742585.5040503@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Dji+lrl2J6ahbT1qhfET0Q)" X-Accept-Language: en-us, en References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 4571 This is a multi-part message in MIME format. --Boundary_(ID_Dji+lrl2J6ahbT1qhfET0Q) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Attached is a revised spec for the fast track, change bars included. Darren --Boundary_(ID_Dji+lrl2J6ahbT1qhfET0Q) Content-type: text/plain; name=2006-662.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=2006-662.txt Summary ======= As part of the BSD4.4 effort to re-implement many of the common shell commands, a common error and warning message interface was introduced. A few subsystems within Solaris have used private implementations of this exact interface with success; given its general utility both for BSD and within Solaris, we propose to add this interface to Solaris's libc as a Committed interface. Patch binding is desired. Details ======= The err() and warn() families of functions have their origins in the release of 4.4BSD and have been a part of all open source BSD releases since that time. The err() and warn() families of functions provide an easy to use interface for emitting an error message via stderr. The both the err-family and warn-family of functions are used to print out a message to stderr. In addition the err-family functions are passed an exit code, and terminate the process by invoking exit(3C) after printing the message. If a NULL format string is supplied, only the program name is displayed on stderr. If a format string is supplied, the program name is immediately followed by ": " and is prepended to the format string on output. | The program name used in output is the filename component of the | pathname returned by getexecname(3C). Once the name is successfully | retrieved, a pointer to it is kept for further use and getexecname(3C) | is not called again.. err(), verr(), warn() and vwarn() all append ": " followed by a system error string, equivalent to that returned by strerror(3c), to the formatted output string. The 'x' variants of these functions do not append either the ": " or the system error string. Analogous to the vprintf family of functions, the 'v' variants of these functions take a va_list parameter, permitting them to be used for building special case functions using varargs. All strings output are terminated with a newline character. The list of functions to being proposed for elevation to "Committed" is: void err(int, const char *, ...); void verr(int, const char *, va_list); void errx(int, const char *, ...); void verrx(int, const char *, va_list); void warn(const char *, ...); void vwarn(const char *, va_list); void warnx(const char *, ...); void vwarnx(const char *, va_list); | Changes to ON | ------------- | Although there are multiple instantiations of vwarn() and warn() | throughout ON today, this project only seeks to migrate one from | a private library to public: that found in lib/libipsecutil/common | as this is the only one that behaves in accordance with the BSD | design. The other implementations of warn/vwarn are encouraged to | migrate to this interface but will not be changed as part of this | case. Examples -------- int fd = open("/nobodyhome", O_RDONLY); warn(NULL); a.out: No such file or directory warn("open"); a.out: open: No such file or directory warn("open(%s,O_RDONLY)", "/nobodyhome"); a.out: open(/nobodyhome,O_RDONLY): No such file or directory warnx(NULL); a.out warnx("open"); a.out: open Copyright --------- While these functions originally appeared in 4.4BSD, they have been clean-room written and thus our code is not required to carry any non-Sun copyright. The manual page included comes from NetBSD 3.0. Interface table =============== +-----------+-------------+-------------------------------+ | Interface | Commitment | Description | +-----------+-------------+-------------------------------+ | | Committed | Header file for new functions | | err | Committed | | | verr | Committed | | | errx | Committed | | | verrx | Committed | | | warn | Committed | | | vwarn | Committed | | | warnx | Committed | | | vwarnx | Committed | | +-----------+-------------+-------------------------------+ --Boundary_(ID_Dji+lrl2J6ahbT1qhfET0Q)-- From sacadmin Mon Dec 4 15:57:53 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB4NvrVs000181 for ; Mon, 4 Dec 2006 15:57:53 -0800 (PST) Received: from [129.150.12.77] (vpn-129-150-12-77.SFBay.Sun.COM [129.150.12.77]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB4Nvq1h945664; Mon, 4 Dec 2006 15:57:53 -0800 (PST) Message-ID: <4574B5F4.6030708@sun.com> Date: Mon, 04 Dec 2006 13:57:40 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Darren Reed CC: PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <45742585.5040503@sun.com> In-Reply-To: <45742585.5040503@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 650 Darren Reed wrote: > | Changes to ON > | ------------- > | Although there are multiple instantiations of vwarn() and warn() > | throughout ON today, this project only seeks to migrate one from > | a private library to public: that found in lib/libipsecutil/common > | as this is the only one that behaves in accordance with the BSD > | design. The other implementations of warn/vwarn are encouraged to > | migrate to this interface but will not be changed as part of this > | case. > > I'm OK with this, and I know its *not* architecture, but is some effort being made to assure ourselves that at least we aren't breaking any of these? - jek3 From sacadmin Mon Dec 4 18:08:12 2006 Received: from sineb-mail-3.sun.com ([192.18.19.10]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB528BjN002853 for ; Mon, 4 Dec 2006 18:08:12 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB52864g023126 for ; Tue, 5 Dec 2006 10:08:06 +0800 (SGT) 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 <0J9S00H0134KKV00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 05 Dec 2006 10:08:06 +0800 (SGT) Received: from [129.158.87.227] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9S0010S39GI7IB@mail-apac.sun.com>; Tue, 05 Dec 2006 10:08:05 +0800 (SGT) Date: Tue, 05 Dec 2006 14:07:22 +1100 From: Darren Reed Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <4574B5F4.6030708@sun.com> Sender: Darren.Reed@Sun.COM To: Joseph Kowalski Cc: PSARC@sac.sfbay.sun.com Message-id: <4574E26A.20101@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <45742585.5040503@sun.com> <4574B5F4.6030708@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 817 Joseph Kowalski wrote: > Darren Reed wrote: > >> | Changes to ON >> | ------------- >> | Although there are multiple instantiations of vwarn() and warn() >> | throughout ON today, this project only seeks to migrate one from >> | a private library to public: that found in lib/libipsecutil/common >> | as this is the only one that behaves in accordance with the BSD >> | design. The other implementations of warn/vwarn are encouraged to >> | migrate to this interface but will not be changed as part of this >> | case. >> >> > > I'm OK with this, and I know its *not* architecture, but is some > effort being > made to assure ourselves that at least we aren't breaking any of these? To me this sounds like additional requirements for testing of ON as part of the preparation of the RTI. See 6495220. Darren From sacadmin Mon Dec 4 18:20:40 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB52Kevl003028 for ; Mon, 4 Dec 2006 18:20:40 -0800 (PST) Received: from [129.150.12.77] (vpn-129-150-12-77.SFBay.Sun.COM [129.150.12.77]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB52Kd7f978238; Mon, 4 Dec 2006 18:20:39 -0800 (PST) Message-ID: <4574D767.1070803@sun.com> Date: Mon, 04 Dec 2006 16:20:23 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Darren Reed CC: PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <45742585.5040503@sun.com> <4574B5F4.6030708@sun.com> <4574E26A.20101@sun.com> In-Reply-To: <4574E26A.20101@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1099 Darren Reed wrote: > Joseph Kowalski wrote: > >> Darren Reed wrote: >> >>> | Changes to ON >>> | ------------- >>> | Although there are multiple instantiations of vwarn() and warn() >>> | throughout ON today, this project only seeks to migrate one from >>> | a private library to public: that found in lib/libipsecutil/common >>> | as this is the only one that behaves in accordance with the BSD >>> | design. The other implementations of warn/vwarn are encouraged to >>> | migrate to this interface but will not be changed as part of this >>> | case. >>> >>> >> >> I'm OK with this, and I know its *not* architecture, but is some >> effort being >> made to assure ourselves that at least we aren't breaking any of these? > > > To me this sounds like additional requirements for testing of ON > as part of the preparation of the RTI. See 6495220. > > Darren Its a *request* that the developer and C-team (who delegate this to the RTI approver) should just think about this. Given a funky enough makefile, its possible that adding these to libc could result in unexpected bindings. - jek3 From sacadmin Tue Dec 5 03:22:14 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB5BMDS5014247 for ; Tue, 5 Dec 2006 03:22:14 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB5BPg1n022658; Tue, 5 Dec 2006 06:25:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kB5BPg55022655; Tue, 5 Dec 2006 06:25:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17781.22326.383687.479670@gargle.gargle.HOWL> Date: Tue, 5 Dec 2006 06:25:42 -0500 From: James Carlson To: Joseph Kowalski Cc: Darren Reed , PSARC@sac.sfbay.sun.com Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-Reply-To: <4574D767.1070803@sun.com> References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <45742585.5040503@sun.com> <4574B5F4.6030708@sun.com> <4574E26A.20101@sun.com> <4574D767.1070803@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 614 Joseph Kowalski writes: > Its a *request* that the developer and C-team (who delegate this to the > RTI approver) > should just think about this. Given a funky enough makefile, its > possible that adding > these to libc could result in unexpected bindings. True, but given that these things have existed for quite some time in other OSes, I suspect that the exposure is fairly minimal. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Dec 5 06:16:18 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB5EGIfC017561 for ; Tue, 5 Dec 2006 06:16:18 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB5EGHjc027470 for ; Tue, 5 Dec 2006 06:16:18 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB5EGBPG019326 for ; Tue, 5 Dec 2006 14:16:12 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9T00L010XYGH00@d1-emea-09.sun.com> (original mail from Vladimir.Kotal@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 05 Dec 2006 14:16:11 +0000 (GMT) Received: from [129.157.18.74] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9T00ME00YY06DS@d1-emea-09.sun.com> for PSARC@sac.sfbay.sun.com; Tue, 05 Dec 2006 14:16:11 +0000 (GMT) Date: Tue, 05 Dec 2006 15:12:57 +0100 From: Vladimir Kotal Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <456EE09C.6020004@sun.com> Sender: Vladimir.Kotal@Sun.COM To: Darren J Moffat Cc: Darren Reed , PSARC@sac.sfbay.sun.com Message-id: <45757E69.7090409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611300819.kAU8JbR6010555@sac.sfbay.sun.com> <456EC53E.8050903@Sun.COM> <456EE09C.6020004@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 907 Darren Reed wrote: > Darren J Moffat wrote: > >> Does this case modify any part of Solaris to actually use these ? > > > No. > >> I believe there has been some discussion about how to do more with FMA >> for software components and this might be either pre-empting that or >> just complentary. >> >> Is the rationale for this case to make it easier to port software that >> already uses them or is it one of code duplication removal in Solaris ? > > > To make it easier to port software that already uses them. I will remove only libipsecutil err.[ch] implementation which is used to get the code into libc. A heads-up will be sent to the gatelings about the possibility of duplicate code removal after the putback. Some code cannot be removed. (e.g. vwarn() used in FMA since it calls functions from FMA or code which works in a slightly different way than "normal" err/warn functions) v. From sacadmin Thu Dec 7 08:23:02 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB7GN2eN012450 for ; Thu, 7 Dec 2006 08:23:02 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id kB7GN2TR022266; Thu, 7 Dec 2006 08:23:02 -0800 (PST) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id kB7GN2Hf022265; Thu, 7 Dec 2006 08:23:02 -0800 (PST) From: Michael Shapiro Message-Id: <200612071623.kB7GN2Hf022265@zion.eng.sun.com> Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-Reply-To: <45757E69.7090409@sun.com> from Vladimir Kotal at "Dec 5, 2006 03:12:57 pm" To: Vladimir.Kotal@sun.com (Vladimir Kotal) Date: Thu, 7 Dec 2006 08:23:02 -0800 (PST) Cc: Darren.Moffat@sun.com, Darren.Reed@sun.com, PSARC@sac.sfbay.sun.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1650 Some additional commentary on this case: Long ago in pgrep, I introduced err() and warn() into the Solaris source base, albeit with slightly different semantics than the interfaces proposed here. Specifically, rather than having the *x() family, I made the printing of the ": \n" suffix conditional on the presence of a newline in the format string. That is, for program "foo": warn("i am sleepy\n") will print "foo: i am sleepy\n" warn("i am sleepy") will print "foo: i am sleepy: No such file or directory\n" This behavior is propagated in most of the instances of the code that was copied from my original pgrep version. It also exists in several formalized interfaces where the behavior can't be changed. For example, mdb_warn() is a documented API which must preserve these semantics, and SMF introduced libuutil which contains uu_warn() and others which also have the same semantics. Since this case appears to be attempting to conform to BSD API behaviors, there's a bit of a conflict here. If you feel that it's vital to preserve the BSD behavior, you need to be very very careful about changing existing code as to where you put the 'x' suffix and where you don't (I volunteer for code review). Also you can't remove the API behaviors above. Finally, many programs have slightly customized versions of these things, with additional flags, special behaviors, alternate syslog paths, and the like. I would suggest ARC guidance here of the form "don't spuriously rewrite everything in sight, focus on replacing only on removing exact duplication." -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sacadmin Thu Dec 7 14:41:54 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB7MfrVX022643 for ; Thu, 7 Dec 2006 14:41:53 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB7MfkUq004430 for ; Fri, 8 Dec 2006 06:41:47 +0800 (SGT) 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 <0J9X00E01DN7GS00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Fri, 08 Dec 2006 06:41:46 +0800 (SGT) Received: from [129.158.87.227] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9X009E1DPL7B3X@mail-apac.sun.com>; Fri, 08 Dec 2006 06:41:46 +0800 (SGT) Date: Fri, 08 Dec 2006 10:40:58 +1100 From: Darren Reed Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <200612071623.kB7GN2Hf022265@zion.eng.sun.com> Sender: Darren.Reed@Sun.COM To: Michael Shapiro Cc: Vladimir Kotal , Darren.Moffat@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <4578A68A.60609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200612071623.kB7GN2Hf022265@zion.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3145 I'll reiterate the intended code changes: 1) move err.c from libipsecutil to libc; 2) if there are any other instances of the *same* code being present in ON, remove those if possible; 3) if and where necessary, rename all use of err/warn and matching function names that exist in other parts of the ON source tree to a private namespace that does not introduce any behavioural problems. There is no intention here to change existing applications, however big or small, to use this new interface - this is a task for those that own that code if they feel it is required as testing all of those changes is beyond this simple project. We've been through ON and have already looked at the mdb/fma code: it was quite clear from reading the code that these implementations were unsuitable for being changed. It is tempting to replace or attempt to replace similar functionality but it is potentially quite fraught. It is probably worth expanding on (3) here - as has warn been renamed to uu_warn() in pgrep, it may be necessary to rename err/warn elsewhere to ensure that the interfaces used remain private and there are is no accidental usage of the new interface through "helpful" run-time linking. Looking back on this, there is an obvious lesson here: implementing our own versions of "standard" interfaces that exist in open source, with different behaviour, can have unintended long term consequenes that make life harder and should be actively discouraged at all levels. Darren Michael Shapiro wrote: >Some additional commentary on this case: > >Long ago in pgrep, I introduced err() and warn() into the Solaris source >base, albeit with slightly different semantics than the interfaces >proposed here. Specifically, rather than having the *x() family, I made >the printing of the ": \n" suffix conditional on the presence >of a newline in the format string. That is, for program "foo": > >warn("i am sleepy\n") will print "foo: i am sleepy\n" >warn("i am sleepy") will print "foo: i am sleepy: No such file or directory\n" > >This behavior is propagated in most of the instances of the code that >was copied from my original pgrep version. It also exists in several >formalized interfaces where the behavior can't be changed. For example, >mdb_warn() is a documented API which must preserve these semantics, >and SMF introduced libuutil which contains uu_warn() and others >which also have the same semantics. > >Since this case appears to be attempting to conform to BSD API behaviors, >there's a bit of a conflict here. If you feel that it's vital to preserve >the BSD behavior, you need to be very very careful about changing existing >code as to where you put the 'x' suffix and where you don't (I volunteer >for code review). Also you can't remove the API behaviors above. Finally, >many programs have slightly customized versions of these things, with >additional flags, special behaviors, alternate syslog paths, and the like. > >I would suggest ARC guidance here of the form "don't spuriously rewrite >everything in sight, focus on replacing only on removing exact duplication." > >-Mike > > From sacadmin Mon Dec 11 06:50:06 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBBEo5Eq012716 for ; Mon, 11 Dec 2006 06:50:06 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id kBBEo4ZL014715 for ; Mon, 11 Dec 2006 06:50:04 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBBEnw1l001132 for ; Mon, 11 Dec 2006 14:49:58 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA4006016IY7000@d1-emea-10.sun.com> (original mail from Vladimir.Kotal@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 11 Dec 2006 14:49:58 +0000 (GMT) Received: from [129.157.18.74] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA400JDW6J9CYPE@d1-emea-10.sun.com>; Mon, 11 Dec 2006 14:49:58 +0000 (GMT) Date: Mon, 11 Dec 2006 15:46:38 +0100 From: Vladimir Kotal Subject: Re: Make err/warn part of Solaris's libc [PSARC/2006/662 Timeout: 12/07/2006] In-reply-to: <200612071623.kB7GN2Hf022265@zion.eng.sun.com> Sender: Vladimir.Kotal@Sun.COM To: Michael Shapiro Cc: Darren.Moffat@Sun.COM, Darren.Reed@Sun.COM, PSARC@sac.sfbay.sun.com Message-id: <457D6F4E.4030905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200612071623.kB7GN2Hf022265@zion.eng.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 738 Michael Shapiro wrote: > Some additional commentary on this case: > > Long ago in pgrep, I introduced err() and warn() into the Solaris source > base, albeit with slightly different semantics than the interfaces > proposed here. Specifically, rather than having the *x() family, I made > the printing of the ": \n" suffix conditional on the presence > of a newline in the format string. That is, for program "foo": > > warn("i am sleepy\n") will print "foo: i am sleepy\n" > warn("i am sleepy") will print "foo: i am sleepy: No such file or directory\n" Yeah, I am aware of that conflict and as Darren said nothing disruptive (semantics-wise) will be done as part of this project. I will add you as a code-reviewer. v.