find_adv_name() errors

Question

The function find_adv_name() found multiple time in BLE central examples is using the global variable m_target_periph_name instead of the parameter name_to_find . There is also some instance of the function checking the size of the name but some other are missing the check.

MartinBL · Accepted Answer

Hi, 
 I had a look at the HRS example in SDK 14.2.0, and it seems like your are right. Just for the record and other users; e.g. in this function: 
 static bool find_adv_name(ble_gap_evt_adv_report_t const * p_adv_report, char const * name_to_find)
{
 ret_code_t err_code;
 data_t adv_data;
 data_t dev_name;

 // Initialize advertisement report for parsing
 adv_data.p_data = (uint8_t *)p_adv_report->data;
 adv_data.data_len = p_adv_report->dlen;

 //search for advertising names
 err_code = adv_report_parse(BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME, &adv_data, &dev_name);
 if (err_code == NRF_SUCCESS)
 {
 if (memcmp(name_to_find, dev_name.p_data, dev_name.data_len) == 0)
 {
 return true;
 }
 }
 else
 {
 // Look for the short local name if it was not found as complete
 err_code = adv_report_parse(BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME, &adv_data, &dev_name);
 if (err_code != NRF_SUCCESS)
 {
 return false;
 }
 if (memcmp(m_target_periph_name, dev_name.p_data, dev_name.data_len )== 0)
 {
 return true;
 }
 }
 return false;
}
 
 the local variable name_to_find is used in the first memcmp() , but the global variable m_target_periph_name is used in the second memcmp() . The correct thing to do would be to use the local variable, name_to_find , in both cases. I suppose the bug doesn't matter if you use the example out of the box, but if you start modifying the examples you might run into trouble when find_adv_name() uses a mix of global and local variables. 
 I'll notify the SDK team. 
 Thanks for reporting.