#18 createService() returns a pointer, with partial patch :-)

[Jan Hustak]

A few people in the forums have had problems with the fact that Bluez.createService() returns a C pointer, converted into a Java integer, as a handle to the service it has created. There are two problems with this:

1. On 64-bit systems, the pointer cannot be meaningfully converted since it is 64 bits long and a Java int is just 32 bits. This breaks compilation on 64-bit systems.

2. Java ints are *signed* which means createService() often returns a negative value. The trouble is that, according to the method's Javadoc, a negative value means failure. Methods in Avetana that call createService() stick to that interpretation and, as a result, they exhibit mysterious "failures" depending on how malloc() feels at the moment :-)

I have created a patch which hopefully solves point No. 2. I have changed the Javadoc so that only -1 indicates failure. I have also adjusted the calling methods to this interpretation. Of course, when malloc() returns 0xffffffff then createService() will still indicate failure when it shouldn't. I have no idea whether that's actually possible but at least it should be very, very rare.

As for point No. 1, it should be solvable by changing the method's declaration to return long rather than int. I'll leave that to someone with a 64-bit system who can properly test it. It should be noted, however, that it will only work until someone tries to compile Avetana on a 128-bit system :-)

The patch was created using "diff -u" against avetanabt-20070719.tgz.

[Jan Hustak]

A patch improving interpretation of createService()'s return value

[Anonymous]

hello, I have 64bit proc. so I can be a tester for the point 1. At the first I try to change definition in BlueZ.cpp but then compilators says that there is another declaration in de_avetana_bluetooth_stack_BlueZ.h. I hawe no idea when and how is generated the *.h file so I stuck. Any ideas?