Is this a bug?

[TheEclectic]

I don't have any BT devices that require a 16 digit PIN so this might not be a problem:
In ./components/driver_bt/bt_app_source.c
static void handle_bt_gap_pin_req(esp_bt_gap_cb_event_t event, esp_bt_gap_cb_param_t *param)

        if (param->pin_req.min_16_digit) {
            ESP_LOGI(TAG,"Input pin code: 0000 0000 0000 0000");
            esp_bt_pin_code_t pin_code = {0};     <<<===== HERE
            esp_bt_gap_pin_reply(param->pin_req.bda, true, 16, pin_code);
        } else {

Other uses of pin_code suggest that we need a character '0' not zero.

[TheEclectic]

I'm not clear on why we maintain the peers_list in the first place; however, we have theses defines

#define PEERS_LIST_MAINTAIN_RESET -129
#define PEERS_LIST_MAINTAIN_PURGE -129

that peers_list_maintain() uses these magic values to RESET or PURGE, but they are the same value so we never actually purge.

[sle118]

Using A2DP as the main output was never a priority. The main goal has always been SPDIF or analog output and BT was used in the early days for testing purpose. It is still there because it works good enough, but you will definitely find some incomplete sections of code. For example, maintaining a list of peers was there to feed into the front end UI.

As for this line of code
esp_bt_pin_code_t pin_code = {0};

it is an aggregate initialization that tells the compiler to fill the entire structure with 0's (NULL).

https://stackoverflow.com/questions/88957/what-does-0-mean-when-initializing-an-object

[TheEclectic]

The question is whether pin_code should be 16 ASCII '0' rather than 16 ASCII NULs.