Doc: clarify NimBLEAddress(uint8_t[6], type) expects MSB-first bytes#424
Doc: clarify NimBLEAddress(uint8_t[6], type) expects MSB-first bytes#424fl4p wants to merge 1 commit into
Conversation
The constructor calls std::reverse_copy on its input, expecting bytes in MSB-first order (Bluedroid's esp_bd_addr_t layout). The previous docstring said "compatibility with bluedroid esp library using native ESP representation," which is correct but ambiguous if the reader doesn't already know the conventions of both stacks. Callers reaching for this constructor with LSB-first bytes (e.g. as they'd come out of NimBLE's own ble_addr_t.val) silently end up with a reversed address — the radio uses val[] directly for HCI commands, so GAP connects target a fictional peer and time out as BLE_HS_ETIMEOUT with no diagnostic. Documentation-only change; behaviour is unchanged. Points readers to NimBLEAddress(ble_addr_t) for LSB-first wire bytes and to NimBLEAddress(const uint64_t&, uint8_t) for hex literals. Refs h2zero#423
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAhoy! This here PR be but a documentation voyage, matey. The MSB-first byte-array constructor fer ChangesNimBLEAddress Constructor Documentation Clarification
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Documentation-only follow-up to #423.
The byte-array
NimBLEAddressconstructor callsstd::reverse_copyon its input — fine for callers passing Bluedroid-style MSB-first bytes (esp_bd_addr_t), but easy to miss for anyone arriving with LSB-first bytes (e.g. straight out of a NimBLEble_addr_t.val) since both layouts are "native ESP." The original docstring said:Updated docstring spells out the expected order, contrasts it with
NimBLEAddress(ble_addr_t)for LSB-first wire bytes, and points hex-literal users atNimBLEAddress(uint64_t, uint8_t)(which is already well-documented).No behaviour change.
How this came up
Tracked down a 100% connect-timeout bug in a NimBLE bridge where I had a
uint64_tMAC, converted to auint8_t[6]in LSB-first wire order, and passed that to this constructor.reverse_copythen stored it MSB-first inval[], NimBLE usedval[]directly as the on-air LE bytes, and everyble_gap_connecttimed out scanning for a peer that doesn't exist. Symptom was indistinguishable from "out of range." Switching to theuint64_tconstructor fixed it immediately. Issue #423 has the full diagnostic story.Summary by CodeRabbit