[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC
On 07/06/22 04:17, Stefano Stabellini wrote: > # Rule 9.1 "The value of an object with automatic storage duration shall not be read before it has been set" > > The question is whether -Wuninitalised already covers this case or not. > I think it does. > > Eclair is reporting a few issues where variables are "possibly > uninitialized". We should ask Roberto about them, I don't think they are > actual errors? More like extra warnings? No, -Wuninitialized is not reliable, as it has plenty of (well known) false negatives. This is typical of compilers, for which the generation of warnings is only a secondary objective. I wrote about that here: https://www.bugseng.com/blog/compiler-warnings-use-them-dont-trust-them On the specifics: $ cat p.c int foo (int b) { int a; if (b) { a = 1; } return a; } $ gcc -c -W -Wall -Wmaybe-uninitialized -O3 p.c $ gcc -c -W -Wall -Wuninitialized -O3 p.c $ Note that the example is less contrived than you might think. See, JF Bastien's talk at 2019 LLVM Developers' Meeting: https://www.youtube.com/watch?v=I-XUHPimq3o More generally, you can only embrace MISRA if you agree on its preventive nature, which is radically different from the "bug finding" approach. The point is rather simple: 1) static analysis alone cannot guarantee correctness; 2) peer review is unavoidable; 3) testing is unavoidable. In order to effectively conduct a peer review, you cannot afford being distracted every minute by the thought "is this initialized? where is it initialized? with which value is it initialized?" In a MISRA setting, you want that the answer to such questions is immediately clear to anyone. In contrast, if you embrace bug finding (that is, checkers with false negatives like the ones implemented by compilers), you will miss instances that you may miss also with testing (testing a program with UB does not give reliable results); and you will likely miss them with peer review, unless you can spend a lot of time and resources in the activity. The checker implemented by ECLAIR for Rule 9.1 embodies this principle: if it says "violation", then it is a definite violation; if it says "caution", then maybe there is no UB, but a human will have to spend more than 30 seconds in order to convince herself that there is no UB. I understand this may sound frustrating to virtuoso programmers, and there are many of them in the open source world. But the truth is that virtuosity in programming is not a good thing for safety-related development. For safety you want code that is simple and straightforward to reason about. Kind regards, Roberto
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |