On Mon, 20 Jun 2011, Hendrik Sattler wrote: > Zitat von Iain Hibbert <plu...@rya-online.net>: > > > On Mon, 20 Jun 2011, Hendrik Sattler wrote: > > > > > > <openobex/obex.h> file, the following: > > > > > > > > #if !defined(bt_addr_t) > > > > # if defined(SOL_RFCOMM) > > > > # if defined(_WIN32) /* Windows */ > > > > # define bt_addr_t BTH_ADDR > > > > # else /* Linux, FreeBSD, NetBSD */ > > > > # define bt_addr_t bdaddr_t > > > > # endif > > > > # else /* no bluetooth stack available */ > > > > # define bt_addr_t unsigned long > > > > # endif > > > > #endif > > > > > > > > does not actually work since SOL_RFCOMM is never defined on BSD at least > > > > (we just use the BTPROTO_RFCOMM value instead), and on BlueZ/Linux it is > > > > only defined where <bluetooth/bluetooth.h> is included prior (otherwise > > > > the problem is masked, by using unsigned long) > > > > > > That is exactly the intended behaviour. If you want to use the bluetooth > > > functions, you must include the proper bluetooth headers, see > > > lib/bluez_compat.h. > > > > Trouble is, the prototypes exist no matter if the bluetooth support is > > wanted, and detecting the type of bdaddr_t according to OS does not > > necessarily mean that the bdaddr_t type is defined.. > > > > For example, on NetBSD bt_addr_t will be set to bdaddr_t which is correct, > > except that if you are writing an obex program that wants to use TcpOBEX > > routines only then the compilation will fail because you didn't include > > the bluetooth header and bdaddr_t is an unknown type.. > > > > Looking at it further, the following would seem to be a more reliable way > > to detect if the type has been declared > > > > 1. Windows > > BTH_ADDR_NULL is defined in <wga/bluetooth/bthdef.h>, included from > > <ws2bth.h> > > > > 2. FreeBSD > > NG_HCI_BDADDR_ANY is defined in <netgraph/bluetooth/include/ng_hci.h>, > > included from <bluetooth.h> > > > > 3. NetBSD (including DragonflyBSD, OpenBSD & OpenSolaris) > > BDADDR_ANY defined in <netbt/bluetooth.h>, included from <bluetooth.h> > > > > 4. BlueZ/Linux > > BDADDR_ANY defined in <bluetooth/bluetooth.h> > > > > all near the appropriate type declaration.. ? > > Maybe we should use whatever is apropriate for that system, see[1]: > #if defined(_WIN32)
I actually disklike this method, for the reason that it breaks when the OS changes even though the feature remains (eg _WIN64 will fail to work in your example :) better to rely just on the feature itself, though it could be better expressed the other way around for safety #if !defined(bt_addr_t) # if defined(BDADDR_ANY) # define bt_addr_t bdaddr_t # elif defined(NG_HCI_BDADDR_ANY) # define bt_addr_t bdaddr_t # elif defined(BTH_ADDR_NULL) # define bt_addr_t BTH_ADDR # endif #endif > Or just use your mentioned PF_BTH/PF_BLUETOOTH approach. No that doesn't work correctly, for the reason I mentioned before.. > BTW: Solaris has bluetooth? That's news to me. Does OpenOBEX need any change > to support this? OpenSolaris (and I guess Illumos now) does contain parts of the NetBSD Bluetooth stack, and the configure script may detect that and act appropriately, but I don't know for sure.. iain ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
