Closed lanyuwen closed 4 years ago
I would not recommend adding general support for uint24_t
integer type. It can add a lot of overhead to the code (since it is not directly supported by most toolchain/platforms).
I think it'd be easier to use uint32_t
as underlying type to store such values . We can add helpers to write/read it correctly in TLVs/buffers/messages when we would need it, e.g., we can add methods in encoding.hpp
like WriteUint24(uint32_t value)
or uint32_t ReadUint24()
(for both little/big endian encodings).
We can add helpers to write/read it correctly in TLVs/buffers/messages when we would need it, e.g., we can add methods in
encoding.hpp
likeWriteUint24(uint32_t value)
oruint32_t ReadUint24()
(for both little/big endian encodings).
This was the comment that triggered this issue: https://github.com/openthread/openthread/pull/5299#discussion_r463926015
Submitted PR https://github.com/openthread/openthread/pull/5329 which should help address this.
Resolved by #5329
Is your feature request related to a problem? Please describe. OpenThread doesn't have the data type
uint24_t
at the moment, and this makes it inconvenient when we need to define a 24 bits long data such as IEE Vendor OUI.Describe the solution you'd like Introduce
uint24_t
data type and related operations.Additional context IEEE Vendor OUI is 24 bits long which is being used in several places of OpenThread such as Vendor Stack Version TLV and Joiner Advertisement TLV.