I actually have exactly this kind of patch already on my local machine as a part of the CBOR changes. I was giong to push them together (Convert Connectivity to only deal in Binary, Convert RI/C++ to use CBOR instead of JSON), but I can do that separately if you'd like.
On Fri, 2015-06-12 at 13:37 +0000, Lankswert, Patrick wrote: > > -----Original Message----- > > From: iotivity-dev-bounces at lists.iotivity.org > > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Jon A. Cruz > > Sent: Friday, June 12, 2015 1:36 AM > > To: jihwan.seo at samsung.com; iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] To add payload length in CAInfo_t for block-wise > > transfer. > > > > On 06/11/2015 07:30 PM, ??? wrote: > > > Dear All > > > > > > Hi. > > > > > > To get payload length in CA Layer, > > > > > > the method related to strlen / strcpy is used like below. > > > > > > > > > "size_t len = strlen(info.payload);" > > > > > > but, if NULL characteristic is included in the payload. > > > CA can't get accurate length of the payload through these methods. > > > > > > so..I think upper layer have to express the payload length through below > > change. > > > > > > typedef struct > > > { > > > > > > CAMessageType_t type; > > > uint16_t messageId; > > > CATokent_t token; > > > uint8_t tokenLength; > > > CAHeaderOption_t *option; > > > uint8_t numOptions; > > > CAPayload_t payload; > > > > > > * size_t payloadLength; // new member of the structure* > > > > > > } CAInfo_t; > > > > > > but, we should discuss it much. > > > > > > since RI layer also have to consider adding RI API for payloadLength. > > > > > > if you have some opinion. > > > > > > please let me know. > > > > > > ps. I have registerd the JIRA - > > > https://jira.iotivity.org/browse/IOT-561 > > > > > > Conceptually much of the code at various layers had been confusing c-strings > > for buffers. There are some significant differences and you've hit upon some > > of them. > > > > This had been pointed out several times in code reviews, and should have > > been followed-up on already. The JIRA ticket can help with that. > > Yes! I am not sure where this was introduced, but the payload is block of > arbitrary octets. It could be a jpeg, JSON, CBOR or other. The CoAP PDU has > length and buffer. The string functions should never been used or introduced. > > I am not sure if it pre-dated the CA rewrite, but it should not have survived > it. I pointed it out in several CA reviews. > > Pat > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
