[Coding Guideline]: Ensure all loops have a termination condition that is provably reachable#305
[Coding Guideline]: Ensure all loops have a termination condition that is provably reachable#305rcseacord wants to merge 7 commits intorustfoundation:mainfrom
Conversation
✅ Deploy Preview for scrc-coding-guidelines ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Interesting rule. Are we sure there aren't safety-critical systems which have at least one thread that loops forever? @rcseacord |
@felix91gr quite possibly. the philosophy behind this rule (which is quite common in MISRA) is that this is pretty dangerous and so it should always be flagged by the analyzer. any time you have an infinite loop in your code will require a deviation permit, meaning that that infinite loops will always be scrutinized more carefully (presumably by a senior engineer who audits these things). Presumably there aren't many of these in any given system (I would guess at most one) so the burden isn't that high. |
|
@guidelines-bot /commands |
|
ℹ️ Available Commands Pass or step away:
Assign reviewers:
Other:
|
|
|
||
| * **Watchdog timeout**: While hardware watchdogs can detect stuck systems, | ||
| relying on watchdog reset as a termination mechanism indicates | ||
| a design failure and may cause loss of critical state. |
There was a problem hiding this comment.
Potentially nitpicking: I thought that "relying on watchdog reset as a termination mechanism indicates a design failure" could be unnecessary.
Is using a hardware watchdog to this end really always a design failure? I do not know.
What about something else such as "relying on watchdog reset as a termination mechanism disables formal verification of system shutdown and may cause loss [...]".
made code examples complete
c070287 to
aa69089
Compare
No description provided.