From sacadmin Fri Mar 4 09:22:20 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 j24HMJSp028526 for ; Fri, 4 Mar 2005 09:22:19 -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 j24HKv2E017399; Fri, 4 Mar 2005 12:20:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j24HKu9f017396; Fri, 4 Mar 2005 12:20:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.39160.970893.750517@gargle.gargle.HOWL> Date: Fri, 4 Mar 2005 12:20:56 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: 2005/145 INADDR_NONE Constant X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1297 I'm sponsoring this fast-track request for Rao Shoaib. The timeout is set to 03/11/2005. Virtually every system that supports TCP/IP and sockets (including Linux, AIX, Winsock, and *BSD) has the constant INADDR_NONE defined in . This symbol represents the error value returned by the Standard inet_addr() function. (The Open Group standards refer to this function as returning (in_addr_t)-1 on error.) Solaris, though, lacks this symbol, and instead defines it in many different places throughout the current ON source base, and likely in other gates as well. Though inet_addr() is an old and mostly "deprecated" function, failing to define this symbol serves only to increase the difficulty in porting to Solaris. This project adds INADDR_NONE to as a Stable interface. A patch/micro release binding is asserted. The man page for inet(3SOCKET) will be updated to indicate that INADDR_NONE is returned by inet_addr() and inet_network() on error, and that (per the standards) this value is equivalent to (in_addr_t)-1. -- James Carlson, IP Systems Group? 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 4 10:11:31 2005 Received: from phys-mpk-2 (phys-mpk-2 [129.146.11.82]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24IBVSp029852 for ; Fri, 4 Mar 2005 10:11:31 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICU00H01AAATN@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.sfbay.sun.com; Fri, 04 Mar 2005 10:10:09 -0800 (PST) Received: from [10.1.1.16] (vpn-129-150-27-231.SFBay.Sun.COM [129.150.27.231]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ICU00196AGPGK@mpk-mail1.sfbay.sun.com>; Fri, 04 Mar 2005 10:10:02 -0800 (PST) Date: Fri, 04 Mar 2005 10:10:01 -0800 From: Ed Gould Subject: Re: 2005/145 INADDR_NONE Constant In-reply-to: <16936.39160.970893.750517@gargle.gargle.HOWL> To: Rao.Shoaib@Sun.COM Cc: psarc@sac.sfbay.sun.com Message-id: <92cc0c57e8f54492eae7740c7b905220@sun.com> MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <16936.39160.970893.750517@gargle.gargle.HOWL> Status: RO Content-Length: 350 On Mar 4, 2005, at 9:20, James Carlson wrote: > This project adds INADDR_NONE to as a Stable > interface. A patch/micro release binding is asserted. Won't this addition cause existing code that includes another definition if INADDR_NONE to fail to compile? Is that sort of incompatibility suitable for a micro release? --Ed From sacadmin Fri Mar 4 10:23: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 j24IN5Sp000197 for ; Fri, 4 Mar 2005 10:23: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 j24ILhwW017638; Fri, 4 Mar 2005 13:21:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j24ILhSk017635; Fri, 4 Mar 2005 13:21:43 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.42807.444189.199491@gargle.gargle.HOWL> Date: Fri, 4 Mar 2005 13:21:43 -0500 From: James Carlson To: Ed Gould Cc: Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2005/145 INADDR_NONE Constant In-Reply-To: Ed Gould's message of 4 March 2005 10:10:01 References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 929 Ed Gould writes: > > On Mar 4, 2005, at 9:20, James Carlson wrote: > > This project adds INADDR_NONE to as a Stable > > interface. A patch/micro release binding is asserted. > > Won't this addition cause existing code that includes another > definition if INADDR_NONE to fail to compile? Most code already deals with this by use of #ifndef, since most platforms (other than Solaris) already define the macro. > Is that sort of > incompatibility suitable for a micro release? That's a fair question. My answer is "yes" because the macro itself is already well-known and thus its appearance will be unsurprising and (obviously enough) doesn't cause binary compatibility problems. -- James Carlson, IP Systems Group? 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 4 10:27:22 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 j24IRMSp000298 for ; Fri, 4 Mar 2005 10:27:22 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j24IQ0i9166537; Fri, 4 Mar 2005 10:26:00 -0800 (PST) Subject: Re: 2005/145 INADDR_NONE Constant From: Darren J Moffat To: James Carlson Cc: Ed Gould , Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com In-Reply-To: <16936.42807.444189.199491@gargle.gargle.HOWL> References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <16936.42807.444189.199491@gargle.gargle.HOWL> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1109960759.1979.11.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 04 Mar 2005 10:26:00 -0800 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 428 On Fri, 2005-03-04 at 10:21, James Carlson wrote: > That's a fair question. My answer is "yes" because the macro itself > is already well-known and thus its appearance will be unsurprising and > (obviously enough) doesn't cause binary compatibility problems. Surely given that it is a MACRO it is impossible for it to cause a binary compatibility problem only a compile error with poorly written source. -- Darren J Moffat From sacadmin Fri Mar 4 10:35:36 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24IZZSp000585 for ; Fri, 4 Mar 2005 10:35:35 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j24IYDAH010428; Fri, 4 Mar 2005 10:34:13 -0800 (PST) Received: from [192.9.61.51] (punchin-rotondo.SFBay.Sun.COM [192.9.61.51]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id j24IY7806451; Fri, 4 Mar 2005 10:34:08 -0800 (PST) Message-ID: <4228AA24.6020207@sun.com> Date: Fri, 04 Mar 2005 10:34:12 -0800 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Gould CC: Rao.Shoaib@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2005/145 INADDR_NONE Constant References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> In-Reply-To: <92cc0c57e8f54492eae7740c7b905220@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 540 Ed Gould wrote: > > On Mar 4, 2005, at 9:20, James Carlson wrote: > >> This project adds INADDR_NONE to as a Stable >> interface. A patch/micro release binding is asserted. > > Won't this addition cause existing code that includes another definition > if INADDR_NONE to fail to compile? Possibly. With the Sun compiler, a macro redefinition produces only a warning (and only if the value is different). I don't know if other compilers will produce an error or if the C standard speaks to this issue. Scott From sacadmin Fri Mar 4 10:38:06 2005 Received: from phys-mpk-2 (phys-mpk-2 [129.146.11.82]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24Ic6Sp000705 for ; Fri, 4 Mar 2005 10:38:06 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICU00C01BKZIE@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.sfbay.sun.com; Fri, 04 Mar 2005 10:36:44 -0800 (PST) Received: from [10.1.1.16] (vpn-129-150-27-231.SFBay.Sun.COM [129.150.27.231]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ICU001NPBOMGK@mpk-mail1.sfbay.sun.com>; Fri, 04 Mar 2005 10:36:22 -0800 (PST) Date: Fri, 04 Mar 2005 10:36:21 -0800 From: Ed Gould Subject: Re: 2005/145 INADDR_NONE Constant In-reply-to: <16936.42807.444189.199491@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sac.sfbay.sun.com, Rao.Shoaib@Sun.COM Message-id: <71836189b9319877b9c1b6221a914946@sun.com> MIME-version: 1.0 (Apple Message framework v619.2) X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <16936.42807.444189.199491@gargle.gargle.HOWL> Status: RO Content-Length: 1255 On Mar 4, 2005, at 10:21, James Carlson wrote: > Ed Gould writes: >> >> On Mar 4, 2005, at 9:20, James Carlson wrote: >>> This project adds INADDR_NONE to as a Stable >>> interface. A patch/micro release binding is asserted. >> >> Won't this addition cause existing code that includes another >> definition if INADDR_NONE to fail to compile? > > Most code already deals with this by use of #ifndef, since most > platforms (other than Solaris) already define the macro. I'm not concerned with definitions added to the imported code, since I expect that does already do the right thing, as you suggest. The description originally posted states Solaris, though, lacks this symbol, and instead defines it in many different places throughout the current ON source base, and likely in other gates as well. I'm concerned about code that includes one of these other "places" (or are those places all code, and not header files?). Perhaps they're all internal and are acceptable fallout from adding what I agree is something that should exist in the standard place. If we don't think a customer would have found one of these other definitions and included it, rather than use the more obvious #ifndef, then I'm satisfied. --Ed From sacadmin Fri Mar 4 10:40:11 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 j24IeBSp000834 for ; Fri, 4 Mar 2005 10:40:11 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j24Icn1s169784; Fri, 4 Mar 2005 10:38:49 -0800 (PST) Subject: Re: 2005/145 INADDR_NONE Constant From: Darren J Moffat To: Scott Rotondo Cc: Ed Gould , Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com In-Reply-To: <4228AA24.6020207@sun.com> References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <4228AA24.6020207@sun.com> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1109961528.1979.20.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 04 Mar 2005 10:38:49 -0800 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 466 On Fri, 2005-03-04 at 10:34, Scott Rotondo wrote: > Possibly. With the Sun compiler, a macro redefinition produces only a > warning (and only if the value is different). I don't know if other > compilers will produce an error or if the C standard speaks to this issue. MACROS are not part of the C standard they are a hack. If one was doing this with the modern C standard you would use const rather than using MACROS but this is history. -- Darren J Moffat From sacadmin Fri Mar 4 10:51:51 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24IppSp001040 for ; Fri, 4 Mar 2005 10:51:51 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j24IoSAH018697; Fri, 4 Mar 2005 10:50:28 -0800 (PST) Received: from [192.9.61.51] (punchin-rotondo.SFBay.Sun.COM [192.9.61.51]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id j24IoN806588; Fri, 4 Mar 2005 10:50:23 -0800 (PST) Message-ID: <4228ADF3.60103@sun.com> Date: Fri, 04 Mar 2005 10:50:27 -0800 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Gould CC: James Carlson , psarc@sac.sfbay.sun.com, Rao.Shoaib@sun.com Subject: Re: 2005/145 INADDR_NONE Constant References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <16936.42807.444189.199491@gargle.gargle.HOWL> <71836189b9319877b9c1b6221a914946@sun.com> In-Reply-To: <71836189b9319877b9c1b6221a914946@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1074 Ed Gould wrote: > I'm not concerned with definitions added to the imported code, since I > expect that does already do the right thing, as you suggest. The > description originally posted states > > Solaris, though, lacks this symbol, and instead defines it in > many different places throughout the current ON source base, > and likely in other gates as well. > > I'm concerned about code that includes one of these other "places" (or > are those places all code, and not header files?). Perhaps they're all > internal and are acceptable fallout from adding what I agree is > something that should exist in the standard place. If we don't think a > customer would have found one of these other definitions and included > it, rather than use the more obvious #ifndef, then I'm satisfied. Good question; I didn't realize what you meant initially. I should wait for Rao to answer, but I couldn't resist taking a quick look. From what I can see, only three of the definitions in ON are in header files, and all of them appear to be private. Scott From sacadmin Fri Mar 4 10:53:37 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24IrbSp001090 for ; Fri, 4 Mar 2005 10:53:37 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.88.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j24IqE2f003676; Fri, 4 Mar 2005 10:52:14 -0800 (PST) Message-Id: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> Date: Fri, 4 Mar 2005 10:52:14 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: 2005/145 INADDR_NONE Constant To: rao.shoaib@sun.com Cc: psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mc9t6AHqv5sKYluivgubwA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 413 I note that for some reason, the macro INADDR_6TO4RRANYCAST in is made visible only if _XPG4_2 is not defined or __EXTENSIONS__ is not defined (a VERY strange combination). Will this case make INADDR_NONE always visible when is included, or will this definition be conditional? Thanks, Don PS Sebastien Roy has agreed to dig into the strange INADDR_6TO4RRANYCAST definition. From sacadmin Fri Mar 4 10:57: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 j24IvdSp001143 for ; Fri, 4 Mar 2005 10:57:39 -0800 (PST) Received: from [192.168.0.3] (vpn-129-150-33-45.Central.Sun.COM [129.150.33.45]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j24IuFlv174573; Fri, 4 Mar 2005 10:56:16 -0800 (PST) Message-ID: <4228AF00.1090800@sun.com> Date: Fri, 04 Mar 2005 10:54:56 -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: Don Cragun CC: psarc@sac.sfbay.sun.com Subject: Re: 2005/145 INADDR_NONE Constant References: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> In-Reply-To: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 612 Don Cragun wrote: >I note that for some reason, the macro INADDR_6TO4RRANYCAST in > is made visible only if _XPG4_2 is not defined or >__EXTENSIONS__ is not defined (a VERY strange combination). > >Will this case make INADDR_NONE always visible when >is included, or will this definition be conditional? > > Thanks, > Don > >PS Sebastien Roy has agreed to dig into the strange >INADDR_6TO4RRANYCAST definition. > > > The definition will always be visible. I have browsed through the code and don't see any conflicting defintion. So I dont think this will break anything. Rao. From sacadmin Fri Mar 4 11:01:32 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 j24J1WSp001164 for ; Fri, 4 Mar 2005 11:01:32 -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 j24J09kj017793; Fri, 4 Mar 2005 14:00:09 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j24J09Do017790; Fri, 4 Mar 2005 14:00:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.45113.733303.983522@gargle.gargle.HOWL> Date: Fri, 4 Mar 2005 14:00:09 -0500 From: James Carlson To: Don Cragun Cc: Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2005/145 INADDR_NONE Constant In-Reply-To: Don Cragun's message of 4 March 2005 10:52:14 References: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 962 Don Cragun writes: > I note that for some reason, the macro INADDR_6TO4RRANYCAST in > is made visible only if _XPG4_2 is not defined or > __EXTENSIONS__ is not defined (a VERY strange combination). That doesn't sound right to me. > Will this case make INADDR_NONE always visible when > is included, or will this definition be conditional? I'd argue for making it visible when INADDR_LOOPBACK is visible, which I believe means "always." It's essentially the same sort of macro as INADDR_LOOPBACK: not defined by any Open Group standard, but commonly available on all BSD sockets implementations. (The standard oddly seems to define only INADDR_ANY and INADDR_BROADCAST ... not sure what that's about.) -- James Carlson, IP Systems Group? 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 4 11:36:34 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24JaYSp002404 for ; Fri, 4 Mar 2005 11:36:34 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.88.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j24JZC2f003751; Fri, 4 Mar 2005 11:35:12 -0800 (PST) Message-Id: <200503041935.j24JZC2f003751@spartan.SFBay.Sun.COM> Date: Fri, 4 Mar 2005 11:35:12 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: 2005/145 INADDR_NONE Constant To: psarc@sac.sfbay.sun.com Cc: Rao.Shoaib@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VN81M3vLL2yrP9cqese6gw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1371 James Carlson writes: > >Don Cragun writes: >> I note that for some reason, the macro INADDR_6TO4RRANYCAST in >> is made visible only if _XPG4_2 is not defined or >> __EXTENSIONS__ is not defined (a VERY strange combination). > >That doesn't sound right to me. Me either. That is why I asked Roy to look at it after I looked at bug ID 4688704 and PSARC/2001/471 and found no indication of why INADDR_6TO4RRANYCAST was added nor why it was partially hidden when it was added. The person who did the putback pointed me to Roy after denying any knowledge on this issue. > >> Will this case make INADDR_NONE always visible when >> is included, or will this definition be conditional? > >I'd argue for making it visible when INADDR_LOOPBACK is visible, which >I believe means "always." It's essentially the same sort of macro as >INADDR_LOOPBACK: not defined by any Open Group standard, but commonly >available on all BSD sockets implementations. > The standards explicitly allow macros starting with INADDR_ to be made visible in even if the macro is not defined by the standard. I believe INADDR_NONE should always be visible (and that is what Rao says will happen). I just wanted to be sure that INADDR_NONE wasn't going to be hidden behind the same strange guards that sometimes make INADDR_6TO4RRANYCAST invisible. From sacadmin Fri Mar 4 11:38:22 2005 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24JcMSp002451 for ; Fri, 4 Mar 2005 11:38:22 -0800 (PST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICU00101EEKWI@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 04 Mar 2005 14:36:59 -0500 (EST) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ICU0083XEHNRY@bur-mail2.east.sun.com>; Fri, 04 Mar 2005 14:36:59 -0500 (EST) Date: Fri, 04 Mar 2005 14:35:29 -0500 From: Sebastien Roy Subject: Re: 2005/145 INADDR_NONE Constant In-reply-to: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <1109964928.2922.109.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200503041852.j24IqE2f003676@spartan.SFBay.Sun.COM> Status: RO Content-Length: 1250 On Fri, 2005-03-04 at 13:52, Don Cragun wrote: > I note that for some reason, the macro INADDR_6TO4RRANYCAST in > is made visible only if _XPG4_2 is not defined or > __EXTENSIONS__ is not defined (a VERY strange combination). > > Will this case make INADDR_NONE always visible when > is included, or will this definition be conditional? > > Thanks, > Don > > PS Sebastien Roy has agreed to dig into the strange > INADDR_6TO4RRANYCAST definition. > I filed bug: 6236373 INADDR_6TO4RRANYCAST macro is protected by an incorrect conditional However, I noted in the bug report comments that there were symbols in that weren't protected by any XPG related conditional and that were not defined by X/Open. Is this a problem for applications that wish to be X/Open compliant? In other words, if I define _XOPEN_SOURCE=500 in my code and include , should I expect that the symbols I'm allowed use out of that header file will also be contained in on another platform that is also compliant to that version of the X/Open standard? If my code compiles, should that mean that my application is portable to any X/Open compliant environment (modulo the version number)? -Seb From sacadmin Fri Mar 4 11:43:40 2005 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24JheSp002618 for ; Fri, 4 Mar 2005 11:43:40 -0800 (PST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICU00301EMQR7@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 04 Mar 2005 14:42:17 -0500 (EST) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ICU00846EQHRY@bur-mail2.east.sun.com>; Fri, 04 Mar 2005 14:42:17 -0500 (EST) Date: Fri, 04 Mar 2005 14:40:47 -0500 From: Sebastien Roy Subject: Re: 2005/145 INADDR_NONE Constant In-reply-to: <200503041935.j24JZC2f003751@spartan.SFBay.Sun.COM> To: Don Cragun Cc: psarc@sac.sfbay.sun.com, Rao.Shoaib@Sun.COM Message-id: <1109965246.2922.113.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200503041935.j24JZC2f003751@spartan.SFBay.Sun.COM> Status: RO Content-Length: 324 On Fri, 2005-03-04 at 14:35, Don Cragun wrote: > The standards explicitly allow macros starting with INADDR_ to be made > visible in even if the macro is not defined by the > standard. That answers my previous question, and I've updated the bug report to note that the guards should just be removed. -Seb From sacadmin Fri Mar 4 12:30:59 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 j24KUwSp004802 for ; Fri, 4 Mar 2005 12:30:59 -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 j24KTTQp010424; Fri, 4 Mar 2005 15:29:29 -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 j24KTTUH018515; Fri, 4 Mar 2005 15:29:29 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j24KTRMN018514; Fri, 4 Mar 2005 15:29:27 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2005/145 INADDR_NONE Constant From: Bill Sommerfeld To: Darren J Moffat Cc: Scott Rotondo , Ed Gould , Rao.Shoaib@sun.com, psarc@sac.sfbay.sun.com In-Reply-To: <1109961528.1979.20.camel@braveheart.SFBay.Sun.COM> References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <4228AA24.6020207@sun.com> <1109961528.1979.20.camel@braveheart.SFBay.Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109968165.18287.72.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 04 Mar 2005 15:29:26 -0500 Status: RO Content-Length: 326 On Fri, 2005-03-04 at 13:38, Darren J Moffat wrote: > MACROS are not part of the C standard they are a hack. Huh? As I compose this message, I have in my hands a copy of the ISO/IEC 9899 2nd edition C standard dated 1999/12/01. section 6.10.3, starting on page 151, defines #define and macro substitution. - Bill From sacadmin Fri Mar 4 13:43:08 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j24Lh8Sp006884 for ; Fri, 4 Mar 2005 13:43:08 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j24LfjLK247552; Fri, 4 Mar 2005 13:41:45 -0800 (PST) Subject: Re: 2005/145 INADDR_NONE Constant From: Darren J Moffat To: Bill Sommerfeld Cc: Scott Rotondo , Ed Gould , Rao.Shoaib@Sun.COM, psarc@sac.sfbay.sun.com In-Reply-To: <1109968165.18287.72.camel@thunk> References: <16936.39160.970893.750517@gargle.gargle.HOWL> <92cc0c57e8f54492eae7740c7b905220@sun.com> <4228AA24.6020207@sun.com> <1109961528.1979.20.camel@braveheart.SFBay.Sun.COM> <1109968165.18287.72.camel@thunk> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1109972504.1979.54.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 04 Mar 2005 13:41:45 -0800 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 450 On Fri, 2005-03-04 at 12:29, Bill Sommerfeld wrote: > On Fri, 2005-03-04 at 13:38, Darren J Moffat wrote: > > > MACROS are not part of the C standard they are a hack. > > Huh? > > As I compose this message, I have in my hands a copy of the ISO/IEC 9899 2nd > edition C standard dated 1999/12/01. > > section 6.10.3, starting on page 151, defines #define and macro > substitution. Then I'm confused and retract what I said. -- Darren J Moffat From sacadmin Sat Mar 12 13:48:39 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 j2CLmdSp009826 for ; Sat, 12 Mar 2005 13:48:39 -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 j2CLlAPg006556; Sat, 12 Mar 2005 16:47:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2CLlAE1006553; Sat, 12 Mar 2005 16:47:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16947.25438.846578.796552@gargle.gargle.HOWL> Date: Sat, 12 Mar 2005 16:47:10 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: 2005/145 INADDR_NONE Constant X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 437 The timer on this case has expired, and the discussion has converged. I've marked it as "closed approved." The final specification (with a note about the INADDR_* namespace) is in the case directory as spec.txt. -- James Carlson, IP Systems Group? 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