Is there any MISRA rule to find this sideeffect?? - Printable Version +- MISRA Discussion Forums (https://forum.misra.org.uk) +-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4) +--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21) +---- Forum: 8.13 Side effects (https://forum.misra.org.uk/forumdisplay.php?fid=168) +---- Thread: Is there any MISRA rule to find this sideeffect?? (/showthread.php?tid=1446) |
Is there any MISRA rule to find this sideeffect?? - sprabhakars - 03-08-2018 I am not sure, if this potential problem is categorized under any MISRA rules?? Code: #include The variable var2 can have some value updated outside this function(may be more than 256) and causing a system crash as the while condition never fails. I run this with PC-Lint and Parasoft's MISRA checker, both doesn't find any error with this portion of code. Re: Is there any MISRA rule to find this sideeffect?? - dg1980 - 06-08-2018 Quote from amplification of rule 9.1: Quote:According to The Standard, objects with static storage duration are automatically initialized to zero Re: Is there any MISRA rule to find this sideeffect?? - sprabhakars - 06-08-2018 sprabhakars Wrote:I just re edited the code for better clarity - Re: Is there any MISRA rule to find this sideeffect?? - dg1980 - 07-08-2018 Unfortunately, both operands to < are "essentially unsigned" so none of the 10.x rules is violated. The printf/return statements however violate rule 2.1 "unreachable code". But as you already witnessed, that is difficult to track down during static analysis (the code needs to be executed during analysis). Re: Is there any MISRA rule to find this sideeffect?? - Francois - 22-08-2018 Hi Isn't there a rule to ensure that comparison is perform on same object type? Re: Is there any MISRA rule to find this sideeffect?? - dg1980 - 04-10-2018 Francois Wrote:HiCheck the table in MISRA C 2012 Appendix D.1: both operands are essentially unsigned. The table in rule 10.1 poses no restrictions on operator < for essentially unsigned operands. If both operands are supposed to be of the same essential type (not just the same essential type category): that is not clearly stated IMHO. IMHO, currently the bug would be catched only if there is a narrowing assignment which is prohibited by rule 10.3 (see below). Anyhow, an official clarification would be nice. Code: #include RE: Is there any MISRA rule to find this sideeffect?? - misra-c - 31-07-2024 Thank you for drawing this to our attention... this appears (at first glance) to have found a gap in our guidelines! The MISRA C Working Group will look into this further and post an update in due course... |