Hi Pawel,
Throw exception is what I suggested first as ?Filtering During casting?. This requires 32bit limit for Integer as specification at least, I think. if (no API break > better performance by half memory for int), C Layer still use int_64t is OK. BR, Uze Choi From: Pawel Winogrodzki [mailto:[email protected]] Sent: Wednesday, January 18, 2017 11:23 AM To: ??? (Uze Choi); 'Thiago Macieira'; Dave Thaler Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder After discussing the issue with <mailto:dthaler at microsoft.com> @Dave Thaler, I have another proposal regarding the possible data loss issue in my previous e-mail: instead of blindly casting we?d throw an exception for out of range values. This way the API surface will remain backward compatible and we will only specify the API?s behavior for invalid values. What do you think? Thanks, Pawel From: Pawel Winogrodzki Sent: Tuesday, January 17, 2017 01:41 To: ??? (Uze Choi) <uzchoi at samsung.com>; 'Thiago Macieira' <thiago.macieira at intel.com> Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Hi Uze, I see your point, that retuning zero for values beyond what 32-bit integers can hold is not the same with current behavior. Currently, if you set OCRepresentation from OCRepPayload containing a too large/small 64-bit integer we just cast it to an ?int? quietly. My idea in general is to still support regular ?int? type exactly the same way we?re doing it now from the OCRepresentation callers? point of view. So the Java APIs won?t need any changes. I want to make OCRepresentation use the 64-bit value for storage, thus making it possible to handle values from the two other sources I?ve mentioned, but the 32-bit get/setValue() can still cast that internal value to an ?int?. This essentially is the same behavior we see now, if we set the internal 32-bit integer from a 64-bit one. In short: * get/setValue<int> will work exactly the same way it used to. * There will be an additional get/setValue<int64_t>(), which can be used in OCF 1.0. Please let me know, if you see issues with that. Also, I'd appreciate others? opinion on the topic. Thanks, Pawel From: <mailto:[email protected]> ??? (Uze Choi) Sent: Thursday, January 12, 2017 8:33 PM To: Pawel Winogrodzki <mailto:pawelwi at microsoft.com> ; 'Thiago Macieira' <mailto:thiago.macieira at intel.com> Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Hi Pawel, Then, I need more correct understanding for following comment. "BUT the retrieved value is greater/smaller than INT_MAX/INT_MIN, getValue<int>() will return the same value it currently does in case of an error (which is zero)." How does Greater then INT return same value with INT container?? Or do you mean exception occurring for oversized case? Anyway, we need to start from the fact to support the 64bit integer, using <int> will cause problem. Considering Java API int_64 is not supported, 32 bit integer support for IoTivity is the only way. Let me check cases what can we do without API change. Assuming IoTivity to support only 32bit int as specification. If A application put the full 32 bit for integer using C++ API. setValue,int> can filter it (we need to additionally implement the blocking code for oversize with error return) If A application put the greater 32 bit for integer using C API. Then, there is no way to block it. In this case 64 bit integer can be transmitted into other 32 bit machine. If this 32 bit machine use getValue<int> will cause data lose. This looks a kind of bug in iotivity. Change API will be only way, I expect. BR, Uze Choi -----Original Message----- From: Pawel Winogrodzki [ <mailto:[email protected]> mailto:pawelwi at microsoft.com] Sent: Friday, January 13, 2017 7:56 AM To: ??? (Uze Choi); 'Thiago Macieira' Cc: <mailto:iotivity-dev at lists.iotivity.org> iotivity- dev at lists.iotivity.org Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Ok, so it seems there are two main concerns related with fixing my problem: 1. We want to maintain backward compatibility. 2. We want to prepare for OCF 1.0 and be able to support 64 bit integers. Here's my proposal: I'll make OCRepresentation use only int64_t internally. I'll explicitly write what (get|set)Value<int>() is supposed to do, so that it cast "int64_t" to "int", BUT the retrieved value is greater/smaller than INT_MAX/INT_MIN, getValue<int>() will return the same value it currently does in case of an error (which is zero). This way all previous applications will work the way they used to, since they relied only on "int" anyway, so we shouldn't expect values outside of this scope. If someone was trying to use other values, then their applications didn't work properly anyway. Also, anyone who consciously uses 64-bit value will be able to do so. What do you think? Thanks, Pawel -----Original Message----- From: ??? (Uze Choi) [ <mailto:uzchoi at samsung.com> mailto:uzchoi@samsung. com] Sent: Wednesday, January 11, 2017 19:14 To: 'Thiago Macieira' < <mailto:thiago.macieira at intel.com> thiago.macieira at intel.com>; Pawel Winogrodzki < <mailto:pawelwi at microsoft.com> pawelwi at microsoft.com> Cc: <mailto:iotivity-dev at lists.iotivity.org> iotivity- dev at lists.iotivity.org Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Proposal to selecting C API had been proposed before but discarded in the IoTivity initial time. Now, already IoTivity C and C++ language ecosystems are working and people are using both. Let's concentrate on how to correctly support them. In case of using integer in the 32 bit machine with C++ and Java language, During casting, data will be lost and especially distorted in case of minus value. Changing and limiting into int32_t will be only way to resolve them I think. Additionally we need to make sure 32 bit size for OCF integer authorized. If not need more consideration. BR, Uze Choi -----Original Message----- From: <mailto:[email protected]> iotivity-dev- bounces at lists.iotivity.org [mailto:iotivity-dev- <mailto:bounces at lists.iotivity.org> bounces at lists.iotivity.org] On Behalf Of Thiago Macieira Sent: Thursday, January 12, 2017 4:46 AM To: Pawel Winogrodzki Cc: <mailto:iotivity-dev at lists.iotivity.org> 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 19:41:09 PST Pawel Winogrodzki wrote: > 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. In my opinion, it should. The distinction between the C and the C++ API exists for reasons that are no longer valid. The C API is too low-level to the point of being obfuscated, like a function "do" that takes 9 parameters, while the C++ API is too high level and does not get enough attention, not to C++ mention that it was designed with intentional disregard for compatibility with older, non-C++11 compilers. We should have a unified API in one language only -- I understand Microsoft's preference would be for a C API. We do need an IoTivity-wide approval for replacement, but we can start adding one meanwhile, intermediate to the existing two, and leave the approval to when it's complete and can show its own benefits. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list <mailto:iotivity-dev at lists.iotivity.org> iotivity-dev at lists.iotivity.org <https://lists.iotivity.org/mailman/listinfo/iotivity-dev> https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170118/a4be4c57/attachment.html>
