From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: Bug in Guile's Posix Networking Date: Sun, 13 Feb 2011 13:34:59 -0500 Message-ID: <2BD09919-BB03-4DD6-AF78-6EE8B206711B@raeburn.org> References: <877hdb76cq.fsf@vir.lan> <33545F7E-7D6A-406F-8B15-501B050181E1@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1297622218 9279 80.91.229.12 (13 Feb 2011 18:36:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Feb 2011 18:36:58 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Feb 13 19:36:54 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PogoX-0006H3-O8 for guile-devel@m.gmane.org; Sun, 13 Feb 2011 19:36:53 +0100 Original-Received: from localhost ([127.0.0.1]:52134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PogoX-0005fh-82 for guile-devel@m.gmane.org; Sun, 13 Feb 2011 13:36:53 -0500 Original-Received: from [140.186.70.92] (port=54897 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pogmm-0004Y2-9z for guile-devel@gnu.org; Sun, 13 Feb 2011 13:35:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pogml-0003av-Jz for guile-devel@gnu.org; Sun, 13 Feb 2011 13:35:04 -0500 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:39054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pogml-0003aq-Hd for guile-devel@gnu.org; Sun, 13 Feb 2011 13:35:03 -0500 Original-Received: by vxb41 with SMTP id 41so2148287vxb.0 for ; Sun, 13 Feb 2011 10:35:02 -0800 (PST) Original-Received: by 10.220.182.76 with SMTP id cb12mr3790391vcb.19.1297622102198; Sun, 13 Feb 2011 10:35:02 -0800 (PST) Original-Received: from squish.raeburn.org (c-24-128-190-224.hsd1.ma.comcast.net [24.128.190.224]) by mx.google.com with ESMTPS id bq5sm434729vcb.32.2011.02.13.10.35.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 10:35:01 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1082) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 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:11600 Archived-At: On Feb 13, 2011, at 08:55, Noah Lavine wrote: > OS X, which I use, has a somewhat weird field-naming situation. The > generic sockaddr structure has sa_len, but sockaddr_in has a sin_len > field. No, that's normal for a traditional C/UNIX API. Each structure's field = names use a prefix that's an abbreviation for the struct type. So = sockaddr_in uses sin_ and not sa_. If this were a pure C++ API we'd have inheritance and could just specify = a length field in the base class "sockaddr" from which the others might = be derived. But for this ancient C/UNIX API, we have different = structures with different field names, and must cast the pointers. > The code I was fixing is creating a sockaddr_in, so in order to > use the sa_len field I would have had to cast a sockaddr_in to a > sockaddr, and it just seemed cleaner to use the sin_len field. It's no > big deal either way, though - this would affect probably 10 or fewer > lines of code no matter what. Yes, that's fine; just ditch the test for sockaddr (no _in) having a = sin_len field. Ken=