From jbeck@eng.sun.com Fri Sep 21 12:03:52 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8LJ3qJT013867 for ; Fri, 21 Sep 2007 12:03:52 -0700 (PDT) Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8LJ0rpO028751 for ; Fri, 21 Sep 2007 12:00:53 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.2.Alpha0+Sun/8.14.2.Alpha0) with ESMTP id l8LJ0pdv777570; Fri, 21 Sep 2007 12:00:51 -0700 (PDT) Message-Id: <200709211900.l8LJ0pdv777570@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: psarc-ext@sun.com Subject: getldapaliasbyname clarification (PSARC/2007/551) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Sep 2007 12:00:51 -0700 From: John Beck Status: RO Content-Length: 992 I am self-sponsoring this fast-track, which expires on 2007-Sep-28. It seeks to clarify that a function previously ARC'd as Evolving never existed but that a related function which was introduced should be Consolidation Private. 0. Related previous ARC cases PSARC 1998/361 - Native LDAP 1. Problem The above case introduced getldapaliasbyname(3n) as an Evolving function with a man page. No function by that (exact) name was ever putback, though. What was putback was __getldapaliasbyname() with no man page. Furthermore, the binding for the latter function in the library's map file is Private, and there is and only ever has been one consumer (sendmail). Therefore I assert that the Native LDAP case was incorrectly specified. 2. Solution This case seeks to clarify that __getldapaliasbyname() is a Consolidation Private interface and that getldapaliasbyname() is not and has never been an Evolving interface. -- John http://blogs.sun.com/jbeck