Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unreliable lookup method used within LBLEEventDispatcher class #89

Closed
sfyang opened this issue Feb 6, 2018 · 2 comments
Closed

Unreliable lookup method used within LBLEEventDispatcher class #89

sfyang opened this issue Feb 6, 2018 · 2 comments
Assignees

Comments

@sfyang
Copy link

sfyang commented Feb 6, 2018

In the LBLEEventDispatcher class defined in LBLE.h and implemented in LBLE.cpp, the EventTable type is a std::multimap container, and the implementation of both the dispatch() and the removeObserver() methods uses std::multimap::find() method to lookup the iterator to the first element in the m_table list.

However, according to the C++ standard, the std::multimap::find() method does NOT guarantee to return the iterator of the first element for elements of the same key in the list, so the outcome of the these two methods could be STL-implementation-dependent.

A possible workaround could be replacing the std::multimap::find() method calls with std::multimap::lower_bound(), which returns an iterator pointing to the first element that is not less than the specified key.

@pablosun pablosun reopened this Feb 6, 2018
@pablosun pablosun self-assigned this Feb 6, 2018
@pablosun
Copy link
Contributor

pablosun commented Feb 6, 2018

Thanks for report this! We will investigate further into this issue.

@pablosun
Copy link
Contributor

Will use equal_range instead when searching for elements with matching keys.

pablosun added a commit that referenced this issue Feb 14, 2018
 * #89: use `equal_range` when searching for elements in STL multimap, instead of using `find`. `find` is not guaranteed to return the first element in the equal range.

 * #90: Add a new set of interfaces to `LBLEClient` that allows user to identify a characteristic by using service index and characteristic index, instead of using UUID. Note that it is possible for a device to have multiple characteristics with the same UUID.

 * #90: Add a new example `EnumerateCharacteristic.ino` that uses the new indices-based interface of `LBLEClient` to list all the services and characteristics in the connected BLE device.

 * #90: Use `bt_gattc_read_charc` instead of `bt_gattc_read_using_charc_uuid` to read characteristics.

 * #91: when calling `bt_gattc_discover_charc`, we need to wait for multiple `BT_GATTC_DISCOVER_CHARC` event. We added new helper function `waitAndProcessEventMultiple` that supports such event waiting behavior.

 * Refactored `LBLEValueBuffer` to support re-interpreting its raw buffer content into String, float, int, and char types.
pablosun added a commit that referenced this issue Feb 26, 2018
## Bug Fixes

* #89: use `equal_range` when searching for elements in STL multimap, instead of using `find`. `find` is not guaranteed to return the first element in the equal range.

 * #90: Add a new set of interfaces to `LBLEClient` that allows user to identify a characteristic by using service index and characteristic index, instead of using UUID. Note that it is possible for a device to have multiple characteristics with the same UUID.

 * #90: Add a new example `EnumerateCharacteristic.ino` that uses the new indices-based interface of `LBLEClient` to list all the services and characteristics in the connected BLE device.

 * #90: Use `bt_gattc_read_charc` instead of `bt_gattc_read_using_charc_uuid` to read characteristics.

 * #91: when calling `bt_gattc_discover_charc`, we need to wait for multiple `BT_GATTC_DISCOVER_CHARC` event. We added new helper function `waitAndProcessEventMultiple` that supports such event waiting behavior.

 * Refactored `LBLEValueBuffer` to support re-interpreting its raw buffer content into String, float, int, and char types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants