> -----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
