Date: Thu, 30 Aug 2007 15:29:07 -0700
From: "Eugene M. Kim" <freebsd.org@ab.ote.we.lv>
To: FreeBSD Bluetooth Mailing List <bluetooth@freebsd.org>
Subject: One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}?
Message-ID: <46D744B3.8080107@ab.ote.we.lv>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D744B3.8080107>