- asserts considered harmful - 5 Updates
- Union of bitfields and larger type on ARM - 3 Updates
| scott@slp53.sl.home (Scott Lurndal): Feb 25 12:12AM >> in that situation - but there's at least a chance of saving the document. >Aborting in unexpected state is likely safest choice for any serious >software. Most serious software (e.g. safety critical or life critical) cannot _abort_ in unexpected state. It needs to fail safe, which isn't just calling 'assert'. We allow static_assert for compile-time invariants, but never asserts at runtime for any reason. |
| David Brown <david.brown@hesbynett.no>: Feb 25 01:23AM +0100 On 25/02/16 01:12, Scott Lurndal wrote: > in unexpected state. It needs to fail safe, which isn't just calling 'assert'. > We allow static_assert for compile-time invariants, but never asserts at > runtime for any reason. That would depend on what you mean by "abort". For some safety systems, an "abort" that immediately disabled all outputs then hangs the processor could be the ideal fail-safe behaviour. Or perhaps "abort" could be used to force the hardware to restart with a minimal fail-safe firmware image. You are free to implement "abort" in whatever way makes sense for the system in question. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 24 05:32PM -0800 On Thursday, 25 February 2016 02:12:18 UTC+2, Scott Lurndal wrote: > >software. > Most serious software (e.g. safety critical or life critical) cannot _abort_ > in unexpected state. It needs to fail safe, which isn't just calling 'assert'. If there are some special ways to do suicide quicker than with abort then indeed do it but don't attempt to repair anything. Don't forget the software just detected that it is insane. Somewhat safety critical system can be such that one process is "running" and other is waiting as "backup". If "running" process aborts then the "backup" takes over becomes "running" (and new "backup" is prepared). That is typically used when downtime of a service must be minimal. Somewhat better safety critical is to run 3 systems in parallel. Design software of each separately by different team. If one will give different output from other two then trust the majority kill the idiot and let 4th system (from 4th team) to take over. That is typically worth it when life of people can be on stake. > We allow static_assert for compile-time invariants, but never asserts at > runtime for any reason. Never try to fix any insanity run-time, it is simply impossible. The defect did slip in and no test did detect it before so running mad software can no way deal with it. It can only suicide fast to give control over to more sane powers. |
| Ian Collins <ian-news@hotmail.com>: Feb 25 03:29PM +1300 David Brown wrote: > could be used to force the hardware to restart with a minimal fail-safe > firmware image. You are free to implement "abort" in whatever way makes > sense for the system in question. Those were certainly considerations for the last few control systems I worked on. The last was a propulsion and helm control system where a dead stop, painful as it could be, was better than destroying an engine or ramming a jetty at 40 knots! An earlier example was a telco power system controller, again, aborting (via assert) and falling back to hardware defaults was better than allowing outputs that could fry millions of dollars of kit. As you say, the result of a "abort" will vary from system to system but in all cases it must happen immediately when a problem is detected, not after some potentially catastrophic attempts at clean up. -- Ian Collins |
| Vir Campestris <vir.campestris@invalid.invalid>: Feb 25 11:05PM On 25/02/2016 02:29, Ian Collins wrote: > The last was a propulsion and helm control system where a dead stop, > painful as it could be, was better than destroying an engine or ramming > a jetty at 40 knots! I'll assume your stuff was pretty good, but... if you're on a destroyer approaching harbour at 40kts, and the engine management throws a wobbly you are in deep doodoo - because it's the brakes as well. There's no such thing as a dead stop on water. The big tankers take _miles_ to stop or turn even when everything is working. Andy |
| spope33@speedymail.org (Steve Pope): Feb 25 12:06AM >the parts (on the ARM, 8-bit, 16-bit and 32-bit types all have "natural" >alignments), and the ordering of the bitfields (which is low bits first >- guaranteed by the ARM EABI, and thus consistent across compilers). Under K&R C the ordering of fields was not guaranteed, but I think this was cleaned up by C99 or possibly somewhat later. OP should see which language standard their compiler uses and refer to that standard and comment appropriately. (In addition to testing the code...) Steve |
| David Brown <david.brown@hesbynett.no>: Feb 25 01:29AM +0100 On 25/02/16 01:06, Steve Pope wrote: >> - guaranteed by the ARM EABI, and thus consistent across compilers). > Under K&R C the ordering of fields was not guaranteed, but I > think this was cleaned up by C99 or possibly somewhat later. I haven't looked at K&R for an older definition, but C11 certainly says that the order of allocation of bit-fields is implementation-dependent. There are some rules about packing, but there is plenty of scope for weird implementations if the compiler writers so fancy. > OP should see which language standard their compiler uses and > refer to that standard and comment appropriately. (In addition to > testing the code...) As long as his compiler follows the ARM EABI (and all serious embedded ARM compilers will do so), there should be no problem - the EABI gives more details for this sort of thing than any of the C or C++ standards. (He could make it a little easier by dropping the bitfields - they are not necessary when the struct fields are uint8_t and the bitfields are 8 bits.) |
| Les Cargill <lcargill99@comcast.com>: Feb 25 12:05PM -0600 bitrex wrote: > frac_low : 8; > }; > } phase_accumulator; If it doesn't, fix it. Endianness is more or less undefined behavior in 'C' so you have to test it. Walk a 1 through phase_accumulator_full and print out ( or just store the result and dump it with a JTAG if you are without a console ). -- Les Cargill |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment