tag:blogger.com,1999:blog-4172950626830217643.post8730490644576700543..comments2024-03-19T00:59:15.574-04:00Comments on Better Embedded System SW: New Peer Review Checklist for Embedded C CodePhil Koopmanhttp://www.blogger.com/profile/11849599272360094243noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-4172950626830217643.post-85807133777069577062024-01-27T14:41:02.367-05:002024-01-27T14:41:02.367-05:00Thanks for the comments Andreas. Indeed concurrenc...Thanks for the comments Andreas. Indeed concurrency gets complicated. This list was developed for small single-microcontroller projects as you suspected.Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-33388854893319019932018-02-12T14:35:22.980-05:002018-02-12T14:35:22.980-05:00That's basically the point of item #0. An ent...That's basically the point of item #0. An entry criterion for peer review is that you've done static analysis and fixed the warnings you are supposed to fixed. I'm an advocate of being completely warning-free for a defined set of application-appropriate warnings, so all you need to do then is make sure that the warning check has turned up clean. <br />If you want to enter peer review without outstanding warnings you can/should then make evaluating the warnings one of the topics. However, in my experience if you have more than a handful of warnings this becomes impractical, and you end up with with the warnings changing so much after every code modification people just give up. Much better would be to permit pragmas to selectively turn off warnings for the few exceptions (i.e., document deviations from the rules) and make peer review of the correctness and appropriateness of those deviations/pragmas part of the review process.Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-7239942734091748542018-02-12T13:30:15.250-05:002018-02-12T13:30:15.250-05:00One addition I'd like to suggest is to incorpo...One addition I'd like to suggest is to incorporate static analysis tool output in the review checklist. In other words: When a piece of code is reviewed, the reviewers also review the warnings that the static analysis tool provides (buffer overruns, data taint, concurrency issues, null pointer dereference, ...) and make sure that they are properly assessed.<br /><br />Thanks for the post<br />Mark Hermeling [GrammaTech]Anonymoushttps://www.blogger.com/profile/07073679598455560517noreply@blogger.com