If the C++ APIs may be modified with disregard to backwards compatibility, then I should be able to switch OCRepresentation to use int64_t as the only supported integer type and thus be compatible with the rest of the code.
I would need to know, if there is a IoTivity-wide approval to perform such changes, before I start working on them. Thanks, Pawel -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Wednesday, January 11, 2017 08:59 To: Pawel Winogrodzki <pawelwi at microsoft.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder On quarta-feira, 11 de janeiro de 2017 00:11:42 PST Pawel Winogrodzki via iotivity-dev wrote: > 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. It's potential, but can't happen because the OIC 1.0, OIC 1.1 protocols do not support any number larger than 2^31 or smaller than 2^31. > I would really appreciate it, if you could share your opinions and > ideas how to solve this problem. There is no problem yet. But OCF 1.0 does support them in the form of the bridging to other ecosystems and with the Swagger 1.0 content formatting, so we need to be able to support that. To be honest, the API in the C++ layer can be dumped and redesigned from scratch. The C API we may need to keep some compatibility with for some time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
