I think this illustrates the basic principal we should be following in regards to encapsulation/modularity.
That is, says "oh, we can use library X without checking things because it has promised to behave" is not safe coding. The app needs to code a bit defensively. Among other things we might assume that a later maintainer of a library might not be as contentious as original developers, etc. In this case we have been told that we can't really recover from problems while using TinyCbor. So it would then stand to reason that as soon as we hit some error we should just stop, as opposed to continue calling functions who's output should be ignored. The "err = err ||" practice should at least give us that. However my experience is that some other paradigm might end up a little more maintainable, as we won't have to explain as much to interns, new coders, etc. We might want to keep this defensive principal and watch that "legal" to call might not always mean "wise" to call. On 10/23/2015 10:58 AM, Keane, Erich wrote: > If the buffer is too short, it is still totally legal to call all of the > later cbor statements, so I'm not sure how that happened. All that > should happen after the first time is that would be the increment of the > 'size needed'. > > The tinycbor library is really good about not writing past the buffer, > unless you lie to it about how much was allocated. I'm sure Thiago > would be really interested to see a situation where this isn't the case. > > -Erich > > On Fri, 2015-10-23 at 17:55 +0000, Light, John J wrote: >> 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-bounces at 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 > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
