From sacadmin Fri Mar 18 10:36:35 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IIaYSp019899 for ; Fri, 18 Mar 2005 10:36:35 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2IIZ37O025931; Fri, 18 Mar 2005 13:35:03 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2IIZ3vg025928; Fri, 18 Mar 2005 13:35:03 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16955.8023.168532.654286@gargle.gargle.HOWL> Date: Fri, 18 Mar 2005 13:35:03 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: 2005/180 Inet_aton X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2789 I'm sponsoring this fast-track request for Rao Shoaib. The timer is set for 03/25/2005. A Micro release binding is asserted. The interface exported is Stable. Most UNIX systems, save Solaris, have had a TCP/IP utility function called 'inet_aton' for ages. This function is similar in purpose to the even older 'inet_addr' function, but repairs an obvious defect in the interface that latter function offers: there's no way to distinguish between the all-ones IPv4 broadcast address and just abject parsing failure. We've avoided adding this function as it didn't fit with our future direction for inet_pton and (later) getaddrinfo. Nevertheless, developers used it and continue to use it for new applications, and were then faced with unnecessary difficulties in porting to Solaris. As a result, many such applications either supply their own (often hackish) version of the function, or just don't compile on Solaris. This case establishes inet_aton as a Stable interface. As with its siblings, this will be exported by libnsl and documented along with the existing functions in inet(3SOCKET). For reference (as this is commonly defined by its behavior on 4.4BSD), the interface is: extern int inet_aton(const char *cp, struct in_addr *addr); Where: 'cp' points to an IPv4 address in one of the classic dotted-decimal forms (a.b.c.d, a.b.c, a.b, or a). 'addr' points to the result to be returned. The return value is 1 if conversion is successful, 0 otherwise. Internally, we currently define this symbol as a "private" interface in libresolv, because that library needs the function to operate correctly. In addition, some users "accidentally" discovered that linking with libresolv made the function available, and likely believe (despite the lack of documentation) that this is the right thing to do on Solaris. The actual implementation will do three things: - Move the existing inet_aton function out of libresolv and into libnsl, making it public in libnsl. - Make inet_aton a weak symbol with the strong _inet_aton used for internal ON libraries (to avoid accidental linkage with user-supplied hackish variants). - Verify, if possible, that existing users who "discovered" the symbol in the wrong location will still see through to the new (and supported) libnsl version. That last bit isn't a requirement of the project, as users who were linking against the private and undocumented symbol accidentally exported by libresolv were already way out on the thin part of the ice. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Mar 18 10:47:00 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IIl0Sp020450 for ; Fri, 18 Mar 2005 10:47:00 -0800 (PST) Received: from heckle (vpn-129-150-29-89.SFBay.Sun.COM [129.150.29.89]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j2IIjRpn628794; Fri, 18 Mar 2005 10:45:28 -0800 (PST) Message-Id: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> Date: Fri, 18 Mar 2005 10:45:06 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/180 Inet_aton To: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com Cc: rao.shoaib@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hE8F4r6Iag9R7XTcjfcgeg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 827 A couple of release binding questions... > A Micro release binding is asserted. The interface exported is > Stable. I know its silly, but do you mean Patch? > - Verify, if possible, that existing users who "discovered" > the symbol in the wrong location will still see through to > the new (and supported) libnsl version. > > That last bit isn't a requirement of the project, as users who were > linking against the private and undocumented symbol accidentally > exported by libresolv were already way out on the thin part of the > ice. Thin ice or not, if such applications do exist and do break I would question the Patch/Micro binding. The customer oriented goal is to keep the view that Patches/Update Releases are "safe". At that point they don't care if the fault is theirs or not. - jek3 From sacadmin Fri Mar 18 10:52:22 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IIqMSp020590 for ; Fri, 18 Mar 2005 10:52:22 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2IIoosn026038; Fri, 18 Mar 2005 13:50:50 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2IIooos026035; Fri, 18 Mar 2005 13:50:50 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16955.8969.960528.326751@gargle.gargle.HOWL> Date: Fri, 18 Mar 2005 13:50:49 -0500 From: James Carlson To: "Joseph E. Kowalski III" Cc: psarc@sac.sfbay.sun.com, Rao.Shoaib@Sun.COM Subject: Re: 2005/180 Inet_aton In-Reply-To: Joseph E. Kowalski III's message of 18 March 2005 10:45:06 References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1037 Joseph E. Kowalski III writes: > > A couple of release binding questions... > > > A Micro release binding is asserted. The interface exported is > > Stable. > > I know its silly, but do you mean Patch? No, Micro -- for Solaris Nevada, the 2.5.1 of our times. > > That last bit isn't a requirement of the project, as users who were > > linking against the private and undocumented symbol accidentally > > exported by libresolv were already way out on the thin part of the > > ice. > > Thin ice or not, if such applications do exist and do break I would > question the Patch/Micro binding. The customer oriented goal is to > keep the view that Patches/Update Releases are "safe". At that point > they don't care if the fault is theirs or not. Fair enough, though I don't think this is needed for a patch. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Mar 18 11:02:43 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJ2hSp023208 for ; Fri, 18 Mar 2005 11:02:43 -0800 (PST) Received: from heckle (vpn-129-150-29-89.SFBay.Sun.COM [129.150.29.89]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j2IJ1AB6634892; Fri, 18 Mar 2005 11:01:11 -0800 (PST) Message-Id: <200503181901.j2IJ1AB6634892@jurassic.eng.sun.com> Date: Fri, 18 Mar 2005 11:00:49 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/180 Inet_aton To: Joseph.Kowalski@eng.sun.com, james.d.carlson@Sun.COM Cc: psarc@sac.sfbay.sun.com, Rao.Shoaib@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jIZy1yh1vjrlq3DCCOx49Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 1410 > > I know its silly, but do you mean Patch? > > No, Micro -- for Solaris Nevada, the 2.5.1 of our times. OK. ... Its Nevada because we don't know if its S11 or S10.1, but the smart money is on S11. Regardless, this gives me a bit more info on how to think about the following... > > > That last bit isn't a requirement of the project, as users who were > > > linking against the private and undocumented symbol accidentally > > > exported by libresolv were already way out on the thin part of the > > > ice. > > > > Thin ice or not, if such applications do exist and do break I would > > question the Patch/Micro binding. The customer oriented goal is to > > keep the view that Patches/Update Releases are "safe". At that point > > they don't care if the fault is theirs or not. > > Fair enough, though I don't think this is needed for a patch. Its been so long since we've done a Micro release, I'm not sure what the customer expectation should/would be. In general, removing an internal interface would be a no-brainer, but entry points which are well known on other systems are a special case. I think I'll just go with the odds that: 1) Nevada is S11 2) Its going to be the very rare and strange link line that does break (if any). Let me just strongly suggest to Rao, that approved or not, if he should find that the breakage is common, please revisit us. I'm done. - jek3 From sacadmin Fri Mar 18 11:03:01 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJ30Sp023223 for ; Fri, 18 Mar 2005 11:03:01 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2IJ1RQp020559; Fri, 18 Mar 2005 14:01:27 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2IJ1Rh6023825; Fri, 18 Mar 2005 14:01:27 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2IJ1Rfu023824; Fri, 18 Mar 2005 14:01:27 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2005/180 Inet_aton From: Bill Sommerfeld To: "Joseph E. Kowalski III" Cc: psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com, Rao.Shoaib@sun.com In-Reply-To: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111172486.22852.181.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 18 Mar 2005 14:01:27 -0500 Status: RO Content-Length: 709 On Fri, 2005-03-18 at 13:45, Joseph E. Kowalski III wrote: > > That last bit isn't a requirement of the project, as users who were > > linking against the private and undocumented symbol accidentally > > exported by libresolv were already way out on the thin part of the > > ice. > > Thin ice or not, if such applications do exist and do break I would > question the Patch/Micro binding. The customer oriented goal is to > keep the view that Patches/Update Releases are "safe". At that point > they don't care if the fault is theirs or not. I think we're not at much risk of breaking anything here -- pretty much any program which would want to use this function links with -lnsl already. - Bill From sacadmin Fri Mar 18 11:07:39 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJ7dSp023247 for ; Fri, 18 Mar 2005 11:07:39 -0800 (PST) Received: from heckle (vpn-129-150-29-89.SFBay.Sun.COM [129.150.29.89]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j2IJ65Z6637351; Fri, 18 Mar 2005 11:06:07 -0800 (PST) Message-Id: <200503181906.j2IJ65Z6637351@jurassic.eng.sun.com> Date: Fri, 18 Mar 2005 11:05:45 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/180 Inet_aton To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com, Rao.Shoaib@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WuY/RD365KmByw6dIZ1U4A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 462 > I think we're not at much risk of breaking anything here -- pretty much > any program which would want to use this function links with -lnsl > already. Right. See my electrons which were travelling East at the same time these electrons were travelling West. Of course, somebody will have: -lresolv -lsome_other_weird_thing_which_exports_inet_aton -lnsl (Just being perverse.... This is rare enough and thin enough ice not to worry about 8^) - jek3 From sacadmin Fri Mar 18 11:08:52 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJ8qSp023288 for ; Fri, 18 Mar 2005 11:08:52 -0800 (PST) Received: from [192.168.0.3] (vpn-129-150-30-253.SFBay.Sun.COM [129.150.30.253]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2IJ7ITs638174; Fri, 18 Mar 2005 11:07:20 -0800 (PST) Message-ID: <423B2691.609@sun.com> Date: Fri, 18 Mar 2005 11:05:53 -0800 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: "Joseph E. Kowalski III" , psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com Subject: Re: 2005/180 Inet_aton References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> <1111172486.22852.181.camel@thunk> In-Reply-To: <1111172486.22852.181.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1106 Bill Sommerfeld wrote: >On Fri, 2005-03-18 at 13:45, Joseph E. Kowalski III wrote: > > >>>That last bit isn't a requirement of the project, as users who were >>>linking against the private and undocumented symbol accidentally >>>exported by libresolv were already way out on the thin part of the >>>ice. >>> >>> >>Thin ice or not, if such applications do exist and do break I would >>question the Patch/Micro binding. The customer oriented goal is to >>keep the view that Patches/Update Releases are "safe". At that point >>they don't care if the fault is theirs or not. >> >> > >I think we're not at much risk of breaking anything here -- pretty much >any program which would want to use this function links with -lnsl >already. > > > Bill is correct. Use of libresolv requires linking with libnsl (see man page).The only issue is what if some application is defining this function and was only linking libnsl. Now it will run into issues. We have one such testsuite. Most freewares check for the existance of this function before defining their own. Rao. > - Bill > > > > > From sacadmin Fri Mar 18 11:11:06 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJB6Sp023384 for ; Fri, 18 Mar 2005 11:11:06 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2IJ9X6A026177; Fri, 18 Mar 2005 14:09:33 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2IJ9X6Z026174; Fri, 18 Mar 2005 14:09:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16955.10093.609422.90667@gargle.gargle.HOWL> Date: Fri, 18 Mar 2005 14:09:33 -0500 From: James Carlson To: Bill Sommerfeld Cc: "Joseph E. Kowalski III" , psarc@sac.sfbay.sun.com, Rao.Shoaib@sun.com Subject: Re: 2005/180 Inet_aton In-Reply-To: Bill Sommerfeld's message of 18 March 2005 14:01:27 References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> <1111172486.22852.181.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 600 Bill Sommerfeld writes: > I think we're not at much risk of breaking anything here -- pretty much > any program which would want to use this function links with -lnsl > already. You'd think. But I think we've (now) already found one such broken consumer. *sigh* Suggest changing that to a mandatory part of the project: linking with libresolv has to give you that symbol. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Mar 18 11:17:28 2005 Received: from phys-aus08-1 (phys-aus08-1.Central.Sun.COM [129.153.131.88]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJHRSp023761 for ; Fri, 18 Mar 2005 11:17:27 -0800 (PST) Received: from conversion-daemon.aus08-mail1.central.sun.com by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDK00501AL2OJ@aus08-mail1.central.sun.com> (original mail from David.Robinson@sun.com) for psarc@sac.sfbay.sun.com; Fri, 18 Mar 2005 13:15:52 -0600 (CST) Received: from [129.153.128.60] (jetsun.Central.Sun.COM [129.153.128.60]) by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IDK0041VAUFBW@aus08-mail1.central.sun.com>; Fri, 18 Mar 2005 13:15:52 -0600 (CST) Date: Fri, 18 Mar 2005 13:15:51 -0600 From: David Robinson Subject: Re: 2005/180 Inet_aton In-reply-to: <423B2691.609@sun.com> To: Rao Shoaib Cc: Bill Sommerfeld , "Joseph E. Kowalski III" , psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM Message-id: <423B28E7.3050903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20050129) References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> <1111172486.22852.181.camel@thunk> <423B2691.609@sun.com> Status: RO Content-Length: 592 Rao Shoaib wrote: > Bill is correct. Use of libresolv requires linking with libnsl (see man > page).The only issue is what if some application is defining this > function and was only linking libnsl. Now it will run into issues. We > have one such testsuite. Most freewares check for the existance of this > function before defining their own. Isn't the standard answer to this problem to define the actual function as _inet_aton and then create a #pragma weak for inet_aton? Then if an existing piece of code has their own version it will quietly be used and not the library. -David From sacadmin Fri Mar 18 11:20:35 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJKZSp023886 for ; Fri, 18 Mar 2005 11:20:35 -0800 (PST) Received: from [192.168.0.3] (vpn-129-150-30-253.SFBay.Sun.COM [129.150.30.253]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2IJJ2kX660239; Fri, 18 Mar 2005 11:19:03 -0800 (PST) Message-ID: <423B2951.7020107@sun.com> Date: Fri, 18 Mar 2005 11:17:37 -0800 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Robinson CC: Bill Sommerfeld , "Joseph E. Kowalski III" , psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com Subject: Re: 2005/180 Inet_aton References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> <1111172486.22852.181.camel@thunk> <423B2691.609@sun.com> <423B28E7.3050903@sun.com> In-Reply-To: <423B28E7.3050903@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 691 David Robinson wrote: > Rao Shoaib wrote: > >> Bill is correct. Use of libresolv requires linking with libnsl (see >> man page).The only issue is what if some application is defining this >> function and was only linking libnsl. Now it will run into issues. We >> have one such testsuite. Most freewares check for the existance of >> this function before defining their own. > > > Isn't the standard answer to this problem to define the actual > function as _inet_aton and then create a #pragma weak for inet_aton? > Then if an existing piece of code has their own version it will > quietly be used and not the library. > > -David Yes. Jim Carlson has already sugested this. Rao. From sacadmin Fri Mar 18 11:20:45 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJKjSp023901 for ; Fri, 18 Mar 2005 11:20:45 -0800 (PST) Received: from heckle (vpn-129-150-29-89.SFBay.Sun.COM [129.150.29.89]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j2IJJBEB660311; Fri, 18 Mar 2005 11:19:13 -0800 (PST) Message-Id: <200503181919.j2IJJBEB660311@jurassic.eng.sun.com> Date: Fri, 18 Mar 2005 11:18:51 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/180 Inet_aton To: Rao.Shoaib@Sun.COM, David.Robinson@Sun.COM Cc: sommerfeld@Sun.COM, Joseph.Kowalski@eng.sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ioMdMlFz0KaFBCPGhH2VGA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 833 > Rao Shoaib wrote: > > > Bill is correct. Use of libresolv requires linking with libnsl (see man > > page).The only issue is what if some application is defining this > > function and was only linking libnsl. Now it will run into issues. We > > have one such testsuite. Most freewares check for the existance of this > > function before defining their own. > > Isn't the standard answer to this problem to define the actual > function as _inet_aton and then create a #pragma weak for inet_aton? > Then if an existing piece of code has their own version it will > quietly be used and not the library. > > -David Yea. Its just that our current implemention (straight from New Jersey) is a bit broken when the symbols are in different libraries. That said, its pretty trivial to make it work for any given symbol. - jek3 From sacadmin Fri Mar 18 11:25:29 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2IJPSSp024007 for ; Fri, 18 Mar 2005 11:25:28 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2IJNu0b026252; Fri, 18 Mar 2005 14:23:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2IJNumv026249; Fri, 18 Mar 2005 14:23:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16955.10956.125088.255703@gargle.gargle.HOWL> Date: Fri, 18 Mar 2005 14:23:56 -0500 From: James Carlson To: David Robinson Cc: Rao Shoaib , Bill Sommerfeld , "Joseph E. Kowalski III" , psarc@sac.sfbay.sun.com Subject: Re: 2005/180 Inet_aton In-Reply-To: David Robinson's message of 18 March 2005 13:15:51 References: <200503181845.j2IIjRpn628794@jurassic.eng.sun.com> <1111172486.22852.181.camel@thunk> <423B2691.609@sun.com> <423B28E7.3050903@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1138 David Robinson writes: > Rao Shoaib wrote: > > > Bill is correct. Use of libresolv requires linking with libnsl (see man > > page).The only issue is what if some application is defining this > > function and was only linking libnsl. Now it will run into issues. We > > have one such testsuite. Most freewares check for the existance of this > > function before defining their own. > > Isn't the standard answer to this problem to define the actual > function as _inet_aton and then create a #pragma weak for inet_aton? > Then if an existing piece of code has their own version it will > quietly be used and not the library. ... and returning to the original proposal: The actual implementation will do three things: [...] - Make inet_aton a weak symbol with the strong _inet_aton used for internal ON libraries (to avoid accidental linkage with user-supplied hackish variants). -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Mar 30 12:03:17 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2UK3GSp010358 for ; Wed, 30 Mar 2005 12:03:16 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2UK1adR014217; Wed, 30 Mar 2005 15:01:36 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2UK1aK5014214; Wed, 30 Mar 2005 15:01:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16971.1440.561054.566788@gargle.gargle.HOWL> Date: Wed, 30 Mar 2005 15:01:36 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: 2005/180 Inet_aton X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 488 This case was approved during ARC business at today's PSARC meeting, with the clarification that checking (and correcting) for accidental breakage is required. The final specification (updated to include that change) is saved as 'spec.txt' in the case directory. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Sep 25 03:08:49 2007 Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8PA8msW026176 for ; Tue, 25 Sep 2007 03:08:49 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8PA5eIa001332 for ; Tue, 25 Sep 2007 10:05:40 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 <0JOX0020139GNR00@fe-emea-09.sun.com> (original mail from Jon.Anderson@sun.com) for psarc@sac.sfbay.sun.com; Tue, 25 Sep 2007 11:05:40 +0100 (BST) Received: from [129.156.173.42] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOX00F4H5D27M10@fe-emea-09.sun.com> for psarc@sac.sfbay.sun.com; Tue, 25 Sep 2007 11:05:27 +0100 (BST) Date: Tue, 25 Sep 2007 11:07:18 +0100 From: Jon Anderson Subject: PSARC/2005/180 Sender: Jonathan.Anderson@sun.com To: psarc@sac.sfbay.sun.com Message-id: <46F8DDD6.1090204@sun.com> Organization: SRPE MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 841 Hi, I have a customer escalation for CR 4944187: http://monaco.sfbay.sun.com/detail.jsf?cr=4944187 The code changes for this were committed as the following PSARC case: http://sac.eng.sun.com/PSARC/2005/180/ This has a micro release binding which means that I currently cannot patch this for Solaris 10. Reading through the mail discussion, it was postulated that linking problems could ensue with other definitions of inet_aton(). However, the discussion seems to conclude that, with the final changes, the risk of this happening is very small indeed. I would like to request a change in release binding to patch so that I can fix the defect listed above in Solaris 10. Thanks, Jon -- Jon Anderson Solaris Revenue Product Engineering Sun Microsystems Inc. SPARC House (UK) Tel: ++44 (0)1252 421 868 Mob: ++44 (0)7747 180 910