On 2/2/19 11:44 AM, Kent Dickey wrote:> In article <48816c44-ddb7-4c2b-8be8-c20d25833f8d@googlegroups.com>, > StateMachineCOM <statemachineguru@gmail.com> wrote: >>> @Phil Hobbs, @Clifford Heath, @Reinhardt Behm, @A.P.Richelieu: >> >> You guys cannot have it both ways. >> >> If you truly believe that your production code is so good that >> assertions will NEVER fire in the field, then why are you so afraid of >> leaving them in the code? Of course, assertions cause some overhead, but >> they give you that last line of defense to do SOMETHING when the system >> goes out of control. >> >> But you apparently ARE afraid that your assertions will fire too often >> in the field. (Otherwise you would not be talking of "the hammer being >> too big"). In this case, your solution is to disable assertions? And to >> do WHAT? Pray that the system will somehow miraculously recover and >> correct itself? What are the chances for this to work? > > You need to realize your assertions can have bugs just like your code. > In fact, I'm sure the bug rate for assertions is at least an order of > magnitude higher than for other code, possibly several orders of magnitude. > > Say you have a routine which returns a pointer to a structure, and a size of > that structure (so it can get bigger in the future). > > struct Thing *my_thing; > ret = get_a_thing(&my_thing, &size); > assert(size == sizeof(Thing)); > > In all of your testing, this will succeed, since Thing will match the > size being returned for now. > > But then an upgrade occurs, and the size returned is bigger. Now, the > code would work fine (the interface is designed to support this by adding > new fields in the future), but now your assert goes off. This is bad--you > basically have made your code fail on a system upgrade. > > This is a trivial example, but it gets at the issue--asserts can test for > finicky details which actually don't matter. And for tesitng, this is fine, > actually probably a good thing, since it makes code assumptions clear. > > You even point out that assertions make the code less robust--you're more > likely to crash. And you expose yourself to crashing in cases where ignoring > the "error" would be innocuous. I get very frustrated at old programs > which now fail due to stupid checks which they should not be doing. > I mean, I'd prefer a program to keep running and think it was the year 1900 > then to hard fail once year 2000 hit. > > Plus, the dirty secret no one wants to say out loud--buggy code that keeps > running is often more useful than code which "stops". We've got a lot of > experiential evidence that pretty massive bugs can often be worked around > to keep a system running. One downside, of course, is buggy code is often > a giant security hole. I don't think there's a magic wand which easily > balances the need to make the code useful and robust, and secure. > > So, what people are clearly saying is: you need at least 2 levels of > assertions, and the assert I gave as an example above definitely should not > be in production code (but is actually fine in your test builds). > In fact, I sometimes use assertions for things I don't know are true, just > to see if testing hits the case. These should not be in production code. > > Kent >I think the religious war over assertions is mostly due to sloppy use of language, specifically whether "assertion" means "the C assert() macro or some near relative that calls abort() or does a hard reset" or "appropriate runtime error checking". All of our positions are closer than they appear. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
How to avoid a task not executed in a real-time OS?
Started by ●January 21, 2019
Reply by ●February 2, 20192019-02-02