Playing with the code, I ran across a situation where the cbor reported an error (because the buffer was too short), and I got a SIGSEGV in a later cbor statement because nobody had tested 'err' yet. Since the buffers are allocated rationally, this is unlikely to happen in practice. Still...
John -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Keane, Erich Sent: Friday, October 23, 2015 10:49 AM To: Macieira, Thiago Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] question about payload coding Yep, thanks Thiago. That is the situation where we use err = err | vs err = err ||, since that is the only error code we are capable of recovering from. On Fri, 2015-10-23 at 10:47 -0700, Thiago Macieira wrote: > On Friday 23 October 2015 17:41:12 Keane, Erich wrote: > > The err = err | <cbor function> is only used in a few places where > > knowing the error afterwards is important, for most situations, the > > error code is pretty meaningless since there is nothing we can do > > about it. > > To be clear: there's only one error code that is important here and > that's the "buffer is too short" when encoding the data. TinyCBOR has > that in a special bit that no other error code will set, so it's guaranteed > to work. > > Moreover, you *can* continue streaming data after you got such an > error and TinyCBOR will then simply count how many bytes it needs, instead of > encoding. > At the end, you can allocate the buffer of the size that TinyCBOR says > it should be and encoding should work (provided you have the same > data, of course). > _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
