I'm not sure I'm getting what you mean? Are you attempting to alter
behavior, or did you find a bug? If you found a bug, feel free to
submit a patch and add Jon A. Cruz to the review.
As far as:
array[i] -> *array+i, I definitely prefer the previous, and I'm not
sure how they would be different...
On Fri, 2015-09-11 at 13:11 +0000, ??? wrote:
> Currently, Samsung implements the sequence type of
> AttributeValue(OCRepPayload ) in C like C++
> I wrote the sequence type of AttributeValue(OCRepPayload ) because C
> doesn't support vector.
>
> when I am using *.c from resoruce/csdk/stack/src because we cannot use
> OCpresentation.cpp for the thin project ,I have problem to exchaange
> "OCRepPayload array (OCRepPayload[] )" as a value.
>
> ie . the following format cannot be sent.
> . { "key1" : {
> {
> "nested key" : "key_01"
> value" : 100
> },
> {
> "nested key" : "key_02"
> "value" : 200
> }
> }
> }
>
> The based file i tested was
> resource/scdk/stack/smaples/linux/SimpleClientServer/ocserver.cpp,
> occlient.cpp.
> Even though they are .cpp, they call c functions intread of c++ functions..
>
>
> while testing and debuging this issue, I found out that
> OCRepPayloadSetPropObjectArray of ocpayload.c has a pointer issue
> line 953 ; increasing i of array[i] in OCRepPayloadClone(array[i])
> jumps too much , so it cannot find the next OCRepPayload correct.
>
> If newArray[i] = OCRepPayloadClone(array[i]) is changed to newArray[i] =
> OCRepPayloadClone((*array +i) ) ;,it seems it works well as intended
>
>
> =============
>
> typedef struct LIGHTRESOURCE
> {
> OCResourceHandle handle;
> bool state;
> int power;
> char strArray[STRARRAYNUMBER][STRARRAYLENTH]; // array string
> int64_t intArray[INTARRAYNUMBER]; //
> array int
> OCRepPayload rcsArray[2];
> } LightResource;
>
> -----------------
>
> {
> ......
> OCRepPayload dupobj[2];
> dimensions[0]=2; dimensions[1]=dimensions[2]=0;
> if(OCRepPayloadGetPropObjectArray(input, "rcsarray", (OCRepPayload
> ***)dupobj, dimensions)) {
>
> memcpy(currLightResource->rcsArray, dupobj,
> RCSTARRAYNUMBER*sizeof(OCRepPayload));
> }
>
> }
> // when I check currLightResource->rcsArray,, it has teh correct
> value.
> return getPayload(gResourceUri, currLightResource->power,
> currLightResource->state,
> currLightResource->strArray, currLightResource->intArray,
> currLightResource->rcsArray);
> }
>
>
>
> OCRepPayload* getPayload(const char* uri, int64_t power, bool state, char
> strArray[][STRARRAYLENTH],
> int64_t* intArray, OCRepPayload* rcsArray)
> {
> ....
> size_t dimensions[MAX_REP_ARRAY_DEPTH]={2,0,0}; ;; just 2 times.
> OCRepPayloadSetPropObjectArray(payload, "rcsarray",( const OCRepPayload**)
> &rcsArray, dimensions ); ///
> ....
> }
>
>
> Given that OCRepresentation.cpp doesn't use OCRepPayloadSetPropObjectArray
> and nobody uses OCRepPayload array (OCRepPayload[] ) yet, I think it is
> possble that it would rather be changed. however I am still believeing my
> testing way may need to get fixed..
>
>
> If you don't mind . Can I submit ocpayload.c directly? otherwise please
> find out the better way or make me correct..
>
>
> thank you
> Rami
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
