I?ve taken a look at the symbols being generated with that type and they definitely prevent debugging of any variable containing if, because the debugger wasn?t able to figure out the correct symbols from the truncated one. The issue doesn?t prevent successful linking, though.
Considering these two facts it seems ok to suppress the warning for the time being and start the deprecation process (once it?s established what that means for IoTivity). On another hand I?d like to ask, if AttributeValue can actually be considered a part of the public API, because its header and structure is not mentioned anywhere on the IoTivity?s site for C++ APIs. In addition to that does the core spec mention the depth of the JSON array?s that IoTivity is supporting? Thanks, Pawel From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Wednesday, February 15, 2017 17:48 To: Pawel Winogrodzki via iotivity-dev <iotivity-dev at lists.iotivity.org>; Nash, George <george.nash at intel.com>; Junghyun Oh <jhvics1 at gmail.com> Subject: Re: [dev] Removing depth 3 arrays from OCRepresentation to fix symbol name length issue Hi Pawel, I see what you're trying to point out, and yes that sample representation that you mentioned below is not the one that I'm using during my implementation. Let me check your patch whether it works fine with my implementations and get back to you. However, even-though your patch works OK, back-word compatibility support from the API level remains. Therefore, I would like to give +1 to George's opinion on "We need to have deprecation policy - APIs". (ex : Leave the APIs for some time with a NOTE like "will be deprecated", and do remove or deprecate when allowed time passed so that the developers could earn some time for testing new patches) By the way, I'm currenly using the code-base of the Iotivity in 1.2-rel branch so the influence that your patch will bring might be NONE if it will not be cherry-picked from the master. :) Thank you. Jay. --------- Original Message --------- Sender : Pawel Winogrodzki via iotivity-dev <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Date : 2017-02-15 05:19 (GMT+9) Title : Re: [dev] Removing depth 3 arrays from OCRepresentation to fix symbol name length issue Hi Jay, I might have not explained the issue correctly. The JSON objects can go as deep as they want and you have only 1-depth arrays in your examples, so there?s no problem there. I?d like to discuss removing support for 3D arrays, which in JSON could be represented with this examples: [ [ [ 1, 5 ], [ 7, 9 ] ], [ [ 12, 55 ], [ 11, -8 ] ] ] I haven?t seen any examples of these being used in IoTivity (except for tests, of course) and thus wanted to suggest removing support for them to fix the issue from my original e-mail. Another idea might be replacing OC::AttributeValue with a struct containing a union of supported types and a type currently stored by the struct. Thanks, Pawel From: Nash, George [mailto:[email protected]] Sent: Tuesday, February 14, 2017 10:42 To: Junghyun Oh <jhvics1 at gmail.com<mailto:jhvics1 at gmail.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] Removing depth 3 arrays from OCRepresentation to fix symbol name length issue Jay, I would suggest posting this same information in gerrit with a -1 review score. The reviewers are most likely also on this mailing list but there is no way to connect this email unless something is posted in gerrit. I agree that the oswg (open source work group) should consider making a deprecation policy. That would make it really clear when it?s appropriate to deprecate something. In past projects I have worked on code was marked deprecated but still supported for a certain amount of time. In my opinion only reason public code should be removed without deprecation is security and critical bugs. George From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Junghyun Oh Sent: Tuesday, February 14, 2017 8:27 AM To: 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] Removing depth 3 arrays from OCRepresentation to fix symbol name length issue Hi Pawel, My name is Jay and am working on utilizing iotivity for several home appliance products. Unfortunately, I have used this depth-3 arrays for some features on those products already and about to get certification test sooner or later. For the back-ward compatibility issue, those APIs related with this depth-3 array thing is required. Here is the example how I am utilizing this feature on those products. Request : GET /Resource_X Response : { ?n? : ?Array Items?, <=== 1 - depth ?x.com<http://x.com>.mycompany.Items? : [ <=== Array property { <=== 2 - depth ?id? : 1, ?actions? : { ?value" : true <=== 3 - depth }, ?targets? : [ ?oic.r.switch.binary" ], }, { <=== 2 - depth ?id? : 1, ?actions? : { ?modes" : ?hello_world? <=== 3 - depth }, ?targets? : [ ?oic.r.mode" ], }, ?.. ] } I would like to say ? I do agree that we may have better way of supporting depth-3 array like features on the iotivity?, however, I think we need to consider deprecating existing APIs more carefully because of the backward compatibility support. Thank you. Jay. 2017. 2. 11. ?? 10:00, Pawel Winogrodzki via iotivity-dev <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> ??: Hi all, Recently I?ve stumbled on an issue regarding the ?AttributeValue? type, which is a boost::variant with 26 types in its template. This makes the compiler truncate the symbol name (under Windows the compiler shows the C4503 warning<https://msdn.microsoft.com/en-us/library/074af4b6.aspx>), because it exceeds 4096 characters. Not only may that cause linking issues, but also makes debugging a lot harder. I?ve looked at the code and it seems that part of that variant (depth 3 arrays) is not used anywhere except for the tests and my suggestion is to remove it, until it?s actually needed. I?ve verified, that this would fix the issue and here?s my code change suggestion, so you can see what changes are required: https://gerrit.iotivity.org/gerrit/#/c/17195/. Please let me know, what are your suggestions. Pawel _______________________________________________ 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 _______________________________________________ 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 Jung-hyun Oh. SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD +82-10-9890-6731 | Beyond your imagination, Always [cid:image001.gif at 01D2891A.18E2AFB0] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=junghyun.oh&do=bWFpbElEPTIwMTcwMjE2MDE0ODE0ZXBjbXMxcDgwYzg5OWIxNmU2Zjg5NTRiZGU5ZjViMTZmMGYwYmJmNCZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170217/894f28d5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13402 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170217/894f28d5/attachment.gif>
