From owner-freebsd-bluetooth@FreeBSD.ORG Thu Aug 30 22:49:00 2007 Return-Path: Delivered-To: bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8400016A417 for ; Thu, 30 Aug 2007 22:49:00 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx0.nttmcl.com (MX0.nttmcl.com [216.69.68.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0EB13C45B for ; Thu, 30 Aug 2007 22:49:00 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from bbq.nttmcl.com (bbq.nttmcl.com [216.69.70.43]) by mx0.nttmcl.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7UMT7sC007868 for ; Thu, 30 Aug 2007 15:29:09 -0700 Message-ID: <46D744B3.8080107@ab.ote.we.lv> Date: Thu, 30 Aug 2007 15:29:07 -0700 From: "Eugene M. Kim" User-Agent: Thunderbird 2.0.0.0 (X11/20070524) MIME-Version: 1.0 To: FreeBSD Bluetooth Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Subject: One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 22:49:00 -0000 Hello, It seems that AF_BLUETOOTH ambiguously identifies three different types=20 of socket=E2=80=94HCI, L2CAP and RFCOMM=E2=80=94each with its own sockadd= r_* type. This=20 deviates from the standard practice where there is a 1:1 mapping between = an AF_* constant and a corresponding sockaddr_* type, and this may, in=20 turn, break usage of system calls such as getsockname(2) and=20 getpeername(2): These calls return a struct sockaddr whose sa_family=20 should uniquely and unambiguously identify the real sockaddr_* struct to = which the returned sockaddr should be type-cast; if sa_family =3D=3D=20 AF_BLUETOOTH, there are three possibilities and an application that=20 calls get{sock,peer}name(2) cannot choose one of them without extra=20 information (namely, the third argument to the socket() call that=20 created the socket). In this light, shouldn't a unique AF_* constant be allocated for each=20 Bluetooth socket type, such as AF_BTHCI, AF_BTL2CAP and AF_BTRFCOMM,=20 instead of just one AF_BLUETOOTH? Regards, Eugene