find_adv_name() errors

[Nicolas Brunner]

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]

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.