[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Bug in Sdp.c?



First of all,

Thank you for helping us with the debugging of sdp.

I have noticed your comments and I will correct them to the next release of the code, which hopefully will be within the next two weeks. We appreciate all feedback on the code, especially on the sdp which today is more of a static function with a lot of hardcoded values.

Second,

The sdp_disconnect_req(u32 sdp_hdl) is not a nice function, but anyway, the sdp_hdl is returned from the sdp_connect_req and actually it is the reference to the sdp_con object but it is casted to an unsigned integer in this case. This solution is temporary and we have just used the sdp_disconnect_req function for testing. 

And finally, we are interested in all help with improving the sdp.

Best Regards

/Mats



> -----Original Message-----
> From: mathieu.gonot@xxxxxxx.com">mailto:mathieu.gonot@xxxxxxx.com]
> Sent: Friday, June 30, 2000 11:48 AM
> To: bluetooth-dev@xxxxxxx.com
> Subject: [bluetooth-dev] Bug in Sdp.c?
> 
> 
> Hi all,
> 
> I think I have discovered some bugs in the file "sdp.c".
> 
> Firstly, in the function sdp_connect_cfm, line 503, there is 
> a loop depending on a counter i which is never incremented:
> 
>   /* Find the connecting sdp_con */
>   while ((i < NB_MAX_OF_SDP) && (!stop)) {
>     if ((sdp_con_list[i].state == SDP_CONNECTING) && 
>        (sdp_con_list[i].initiator == TRUE)) {
>       sdp = &sdp_con_list[i];
>       stop = TRUE;
>     }
> 
>     i++; // Should logically be added here...
> 
>   }
> I haven't tested it, but that seems strange...
> 
> 
> Secondly, in the function "process_service_search_req", line 
> 1006 and 1013, we have:
> 
>   /* Just skip the next byte since we know that the next 
> parameter is a 
>      16-bit count */
>   data += 1;
> 
> and 
> 
>    /* Just skip the next byte since we know that the next 
> parameter is a 
>      8-bit count */
>   data += 1;
> 
> These two lines should be removed since they are useless and 
> introduce memory problems.
> The same lines in the function "process_service_attr_req", 
> lines 1041 and 1047 should be removed.
> 
> Finally, I don't understand how can I get in my application 
> the necessary  handle to call the function 
> "sdp_disconnect_req(u32 sdp_hdl)",
> since only the remote bluetooth address and a reference to a 
> profile structure are provided as parameters during the connection...
> 
> Cheers,
> 
> Mathieu GONOT
> 
> International Technology Centre Leuven
>