I think According to the OCF specification, from int64_t OCRepPayloadPropType should be changed into int32_t.
Even though it will break the API backward compatibly it should be done. Now, C++ and Java API has only support int then it should have value check logic not to exceed 32 bit size. BR, Uze Choi From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Pawel Winogrodzki via iotivity-dev Sent: Wednesday, January 11, 2017 9:12 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Hi, There?s a problem with how integers are stored and passed between the objects mentioned in the subject. OCRepresentation supports only ?int?, while cbor and OCRepPayload only ?int64_t?. OCRepresentation::setPayload() initializes OCRepresentation from an OCRepPayload object and this causes a potential loss of data, since it has to perform a int64_t->int cast. Simply adding ?int64_t? support to OCRepresentation is not a trivial task, because it?s possible to convert OCRepresentation content to OCRepPayload and back (see RepresentationEncoding::BaseAttributeTest for examples). If the initial OCRepresentation type was ?int?, we will lose this information and encounter an error, while using OCRepresentation::getValue<int>() afterwards. Similarly, enabling OCRepPayload to be aware of the integer type is difficult to accomplish, because we?re using cbor for the JSON <-> OCRepPayload conversions and the same loss of integer type information would occur there as well. I would really appreciate it, if you could share your opinions and ideas how to solve this problem. Thanks, Pawel Winogrodzki -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170111/f9198bbf/attachment.html>
