AH! I see the bug now!
array is of type OCRepPayload**!
The array[i] should REALLY be (*array)[i];
Thats why it looks like it is jumping around. Good catch! If you'd
like to submit a patch, I'm sure it wouldn't have a problem getting
accepted.
On Fri, 2015-09-11 at 16:05 +0000, Keane, Erich wrote:
> 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
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
