[LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

[Eyal Birger]

On Sat, Jun 4, 2016 at 6:27 PM, Matthias Schiffer
<mschiffer at universe-factory.net> wrote:
> On 06/03/2016 04:55 PM, Eyal Birger wrote:
>>
>> Hi,
>>
>>> On 3 Jun 2016, at 13:11, Matthias Schiffer <mschiffer at universe-factory.net> wrote:
>>>
>> (snip)
>>>
>>> 1) and 2) would allow blobmsg to store everything that json-c can (with the
>>> caveat that json-c stores integers as int64 internally, while blobmsg_json
>>> uses int32) -
>>
>> We also noticed this as a problem for us since when converting json strings to blobmsg, integers become signed and thus no more than INT32_MAX can be used.
>>
>> Do you plans to approach this in your patchsets?
>>
>> Eyal
>
> I don't think this can be fixed easily without having to adjust all
> blobmsg_json users, as the blobmsg_policy entries contain
> BLOBMSG_TYPE_INT32 everywhere. I don't know how much the ubus methods are
> considered unchangeable ABI.
>
> Possible approaches include:
>
> 1) Always map JSON intergers to int64. Will cause an incompatible ABI
> change for all ubus calls when used with blobmsg_json.
>
> 2) Add new blobmsg_add_json_* functions which use int64. The caller of a
> ubus method would need to know if the service excepts int32 or int64
> integers, making this more or less unusable for the ubus CLI tool
>
> 3) Adjust blobmsg_add_json_* to encode integers as int32 or int64 depending
> on the value itself. We'd need to extend the blobmsg_policy with some kind
> of BLOBMSG_TYPE_INT which accepts both int32 and int64, and add a
> blobmsg_get_int function that can work with different lengths. Existing
> software would continue to work as long as the supplied values fit into an
> int32.
>

Alas, I think this may still cause an ABI change, as the current int32
implementation caps
values at INT32_MAX; so when BLOBMSG_TYPE_INT32 is specified in the
policy, a value
is _always_ available, whereas in this solution, sometimes it won't
be. Am I wrong?

> 4) Introduce a new BLOBMSG_TYPE_INT type for variable-length integers,
> together with a blobmsg_get_int function (note that, in contrast to 3),
> BLOBMSG_TYPE_INT is a real blobmsg type in this approach). The length of
> records is encoded in the blobmsg format already. Again, this approach
> would need all software to be adjusted.
>
> 1) and 4) are very similar and would cause a hard ABI break for many ubus
> methods. If we want to avoid a flagday change, 3) seems like the best
> option - or some other approach I haven't listed?
>

I tried to think of a way in which we can have blobmsg_format_element() encode
*both* int32 and int64 values at the same time. It might work for parsing,
but won't work with the current serialization code, not to mention
that it would be
a very ugly hack.

Eyal.

> Matthias