From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: doc getsockopt, setsockopt Date: Sat, 01 Oct 2005 09:06:56 +1000 Message-ID: <87k6gyi29b.fsf@zip.com.au> References: <87k6h0g9qd.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1128122123 9364 80.91.229.2 (30 Sep 2005 23:15:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Sep 2005 23:15:23 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Oct 01 01:15:17 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ELU57-0002vT-MC for guile-devel@m.gmane.org; Sat, 01 Oct 2005 01:14:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELU56-00021B-Nn for guile-devel@m.gmane.org; Fri, 30 Sep 2005 19:14:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ELTyG-0000T7-I1 for guile-devel@gnu.org; Fri, 30 Sep 2005 19:07:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ELTyA-0000QN-4N for guile-devel@gnu.org; Fri, 30 Sep 2005 19:07:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELTy9-00009Y-5a for guile-devel@gnu.org; Fri, 30 Sep 2005 19:07:09 -0400 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ELTy8-0001h2-5D for guile-devel@gnu.org; Fri, 30 Sep 2005 19:07:08 -0400 Original-Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8UN73uw019573; Sat, 1 Oct 2005 09:07:03 +1000 Original-Received: from localhost (ppp27FA.dyn.pacific.net.au [61.8.39.250]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8UN70w2010363; Sat, 1 Oct 2005 09:07:02 +1000 Original-Received: from gg by localhost with local (Exim 3.36 #1 (Debian)) id 1ELTxw-0000fj-00; Sat, 01 Oct 2005 09:06:56 +1000 Original-To: Greg Troxel Mail-Copies-To: never In-Reply-To: (Greg Troxel's message of "30 Sep 2005 11:58:11 -0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5250 Archived-At: Greg Troxel writes: > > NetBSD does not define SOL_IP. SOL_SOCKET is 0xffff. So from the > NetBSD point of view, the right thing to do is define > IPPROTO_{IP,UDP,TCP} as (constant) variables. The posix spec at http://www.opengroup.org/onlinepubs/007904975/functions/getsockopt.html gives IPPROTO_TCP as an example, so yep, I'll remove the SOL bits in favour of IPPROTO. I'd noticed in the past the gnu/linux "man 5 protocols" says to use /etc/protocols instead of numbers like IPPROTO, but what posix says must trump that. > NetBSD's Linux compatibility code indicates that SOL_IP is 0, but has > a comment that these values can vary by architecture That should be ok, we don't care about the actual values as long as the constants are right. > It would be interesting to hear what variables the Linux kernel > actually compares to - IPPROTO_IP or SOL_IP. Oh, well, there should be a better spec for the programming interface than digging around the sources :-). > 'man 7 ip' is Linux specific (it's ip(4) on BSD). Perhaps "Consult > operating system documentation for these calls". Thanks, I'll put "man ip" (there should be only one). > MULTIADDR is the multicast group to be joined or left, and > INTERFACEADDR is an IP adddress by which an interface will be found to > perform the join/leave operation. INTERFACEADDR may be INADDR_ANY in > which case the default interface will be used. These values are simply > passed to the underlying system call, so extensions on some systems to > specify interface by ifindex may be available. Sounds fair. > Or skip the last sentence, or the second half of it. People who > understand specifying interfaces by ifindex will hopefully realize the > portability issues of that. Do you need to know about host vs network byte order to get it through? That would be something to note. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel