dhcpv6: refactor u8 and u16 to u32 to avoid boolean coercion - #117
Merged
Merged
Conversation
Member
|
@systemcrash I think it's time to fix this at libubox... |
Contributor
Author
|
If you feel up to that (I wrote to Felix) then that's an option. But this works today. I've had to employ this workaround elsewhere... |
Member
|
systemcrash
force-pushed
the
ubus_fixes
branch
from
November 10, 2025 17:26
81f4c7a to
70ad180
Compare
systemcrash
changed the title
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 <newtwen+github@gmail.com> Link: openwrt#117 Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Member
|
Mrged, thanks @systemcrash! |
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
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.
ubus has been weird for a while, and one workaround suitable is to amend u8 values (despite them being and containing only a u8 int) to u16 values. ubus coerces u8 to booleans for some reason. The actual values on the bus might be a u8, but 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_u16 to resolve this.
ping @Noltari