blobmsg: remove INT8 and INT16 types #25
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
|
NACK. I'd prefer to just deprecate treating u8 as integer and deprecate using u16 in blobmsg entirely. That way we can avoid a lot of compatibility mess and JSON conversion issues. Due to padding, u8, u16 and u32 attributes have the same effective size anyway, so there isn't really a good reason to use them for integer values. |
So u8 always becomes boolean, and anything numeric should use u32? |
Member
|
Yes. Either u32 or u64 (if bigger values are required). |
|
Ah. I see. Could you put a heads-up in the or a readme or somewhere appropriate for this, please? |
systemcrash
added a commit
to systemcrash/odhcp6c
that referenced
this pull request
Nov 10, 2025
ubus coerces u8 to boolean, and one workaround suitable is to amend u8 values (despite them being and containing only a u8 int) to u32 values. ubus coerces u8 to booleans due to historical reasons. Any calls to e.g. ubus call odhcp6c.eth1 get_state (and subsequently downstream dependencies which use this invocation) return booleans(!) where there shall be a number. Amended calls to blobmsg_add_u8 into blobmsg_add_u32 to resolve this. Amended calls to blobmsg_add_u16 into blobmsg_add_u32 also. Apparently u8 and u16 get padded to u32 anyway. See @nbd168 openwrt/libubox#25 (comment) " I'd prefer to just deprecate treating u8 as integer and deprecate using u16 in blobmsg entirely. That way we can avoid a lot of compatibility mess and JSON conversion issues. Due to padding, u8, u16 and u32 attributes have the same effective size anyway, so there isn't really a good reason to use them for integer values. " Signed-off-by: Paul Donald <[email protected]>
|
might need a transition shim since there are some downstream users of |
Noltari
changed the title
Noltari
pushed a commit
to systemcrash/odhcp6c
that referenced
this pull request
Nov 11, 2025
ubus coerces u8 to boolean, and one workaround suitable is to amend u8 values (despite them being and containing only a u8 int) to u32 values. ubus coerces u8 to booleans due to historical reasons. Any calls to e.g. ubus call odhcp6c.eth1 get_state (and subsequently downstream dependencies which use this invocation) return booleans(!) where there shall be a number. Amended calls to blobmsg_add_u8 into blobmsg_add_u32 to resolve this. Amended calls to blobmsg_add_u16 into blobmsg_add_u32 also. Apparently u8 and u16 get padded to u32 anyway. See @nbd168 openwrt/libubox#25 (comment) " I'd prefer to just deprecate treating u8 as integer and deprecate using u16 in blobmsg entirely. That way we can avoid a lot of compatibility mess and JSON conversion issues. Due to padding, u8, u16 and u32 attributes have the same effective size anyway, so there isn't really a good reason to use them for integer values. " Signed-off-by: Paul Donald <[email protected]> Link: openwrt#117 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Noltari
added a commit
to Noltari/libubox
that referenced
this pull request
Nov 11, 2025
u8 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Noltari
added a commit
to Noltari/libubox
that referenced
this pull request
Nov 11, 2025
u16 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Noltari
added a commit
to Noltari/libubox
that referenced
this pull request
Nov 11, 2025
u8 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Noltari
added a commit
to Noltari/libubox
that referenced
this pull request
Nov 12, 2025
u16 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Noltari
added a commit
to Noltari/libubox
that referenced
this pull request
Nov 12, 2025
u8 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
u16 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
u8 has the same effective size as u32 so we can remove it to avoid a lot of compatibility mess and JSON conversion issues. Link: openwrt#25 Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Member
|
I'd prefer to just deprecate int8/int16 support without actually removing it. |
Member
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add proper types for BOOL and INT8 instead of mixing them.
This allows using blobmsg_add_u8 for uint8_t without converting values to
true or false.
Note: I didn't have time to test it yet.
CC @Alphix @systemcrash