Hi Harish, Sorry for no update for such a long time ? I?m currently trying to fix the issue as part of my change here: https://gerrit.iotivity.org/gerrit/#/c/18517 (don?t worry ? it?ll get broken down into smaller chunks). I?ll keep you updated on the issue. I?m going with the approach discussed below ? supporting both ?int? and ?int64_t?, but holding the value only in an ?int64_t? type and throwing exceptions if a data loss occurs.
Thanks, Pawel From: Harish Kumara Marappa [mailto:[email protected]] Sent: Tuesday, May 2, 2017 22:24 To: Pawel Winogrodzki <pawelwi at microsoft.com>; ??? <uzchoi at samsung.com> Cc: thiago.macieira at intel.com; Dave Thaler <dthaler at microsoft.com>; ASHOKBABU CHANNA <ashok.channa at samsung.com>; iotivity-dev at lists.iotivity.org Subject: FW:RE: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Dear Pawel and Mr. Choi, Is there is any update on this issue ? There is a jira ticket created on the same issue https://jira.iotivity.org/browse/IOT-1726<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-1726&data=02%7C01%7Cpawelwi%40microsoft.com%7C938b682fe5dd46b6959b08d491e49a2d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293858411415182&sdata=Jppc05hVs88tTo196nGqO4Bf161tX6cnkAwNSQb0sQY%3D&reserved=0>, its still being opened. Please let me know If anybody is handling this issue currently, so I can move this issue to concerned person. ------- Original Message ------- Sender : Pawel Winogrodzki Date : 2017-02-02 15:15 (GMT+05:30) Title : RE: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder To : h.marappa at samsung.com<h.marappa at samsung.com<mailto:h.marappa at samsung.com%3ch.marappa at samsung.com>>, 'Thiago Macieira'<thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>, Dave Thaler<dthaler at microsoft.com<mailto:dthaler at microsoft.com>> Cc : ???<uzchoi at samsung.com<mailto:uzchoi at samsung.com>>, iotivity-dev at lists.iotivity.org<iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org%3ciotivity-dev at lists.iotivity.org>> As part of my current task<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.iotivity.org%2Fbrowse%2FIOT-1583&data=02%7C01%7Cpawelwi%40microsoft.com%7C938b682fe5dd46b6959b08d491e49a2d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293858411415182&sdata=otPOuGGmkjpKyMWtIGCAqB6x3sG29uvP1793Jx%2FD2eo%3D&reserved=0> I?ve got a proposal queued and I should get to it within ~2 weeks. The idea is what Uze/Dave suggested ? support the ?int? type, make OCRepresentation use ?int64_t? internally and throw an exception if someone tries to retrieve an ?int?, but the value is beyond its range. Thanks, Pawel From: Harish Kumara Marappa [mailto:[email protected]] Sent: Thursday, February 2, 2017 01:22 To: Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>>; 'Thiago Macieira' <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>; Dave Thaler <dthaler at microsoft.com<mailto:dthaler at microsoft.com>> Cc: ??? <uzchoi at samsung.com<mailto:uzchoi at samsung.com>>; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder Hi Pawel, I am facing same integer data loss issue in one of my use case. I could not follow up this thread recently. Is there any fix going on for this issue? Regards, Harish Kumara M --------- Original Message --------- Sender : Uze Choi <uzchoi at samsung.com<mailto:uzchoi at samsung.com>> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : 2017-01-18 16:36 (GMT+5:30) Title : Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder 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<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder After discussing the issue with @Dave Thaler<mailto:dthaler at microsoft.com>, 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<mailto:uzchoi at samsung.com>>; 'Thiago Macieira' <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> Cc: iotivity-dev at lists.iotivity.org<mailto: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: ??? (Uze Choi)<mailto:[email protected]> 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<mailto: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]] Sent: Friday, January 13, 2017 7:56 AM To: ??? (Uze Choi); 'Thiago Macieira' Cc: iotivity-dev at lists.iotivity.org<mailto: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:[email protected]] Sent: Wednesday, January 11, 2017 19:14 To: 'Thiago Macieira' <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>; Pawel Winogrodzki <pawelwi at microsoft.com<mailto:pawelwi at microsoft.com>> Cc: iotivity-dev at lists.iotivity.org<mailto: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: iotivity-dev-bounces at lists.iotivity.org<mailto:[email protected]> [mailto:iotivity-dev- bounces at lists.iotivity.org<mailto:bounces at lists.iotivity.org>] On Behalf Of Thiago Macieira Sent: Thursday, January 12, 2017 4:46 AM To: Pawel Winogrodzki Cc: iotivity-dev at lists.iotivity.org<mailto: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 iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Cpawelwi%40microsoft.com%7C938b682fe5dd46b6959b08d491e49a2d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293858411415182&sdata=Euv5il0ZLGc6iGynzDboQftQ806%2BXPGzrpXHkOJHdHw%3D&reserved=0> _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Cpawelwi%40microsoft.com%7C938b682fe5dd46b6959b08d491e49a2d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293858411415182&sdata=Euv5il0ZLGc6iGynzDboQftQ806%2BXPGzrpXHkOJHdHw%3D&reserved=0> [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=h.marappa&do=bWFpbElEPTIwMTcwMjAyMDkyMjIyZXBjbXM1cDZkZWE0ZTI1MTcyN2UwOWM5MmE2MjFmNGZkZTcxYjdiMCZyZWNpcGllbnRBZGRyZXNzPXBhd2Vsd2lAbWljcm9zb2Z0LmNvbQ__] [cid:image001.png at 01D2C396.AE26BA10] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=h.marappa&do=bWFpbElEPTIwMTcwNTAzMDUyMzU2ZXBjbXM1cDViZjI4N2QyNTg3M2ZjMzZlYzQyYWY2ZWIwYjg1ZjJhZiZyZWNpcGllbnRBZGRyZXNzPXBhd2Vsd2lAbWljcm9zb2Z0LmNvbQ__] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170503/548154b3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: image001.png URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170503/548154b3/attachment.png>
