> On 9 Jun 2022, at 12:24, Jan Beulich <[email protected]> wrote: > > On 09.06.2022 13:11, Roberto Bagnara wrote: >> 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; >> } >>
> I understand what you're saying, yet I'd like to point out that adding > initializers "blindly" may give a false sense of code correctness. > Among other things it takes away the chance for tools to point out > possible issues. Plus some tools warn about stray initializers ... Right — if you always set “int a=0;”, then you’re getting a known value; but if your algorithm relies on it being something specific (and not zero), then it’s not clear the resulting software is actually more reliable. If you don’t initialise it, there’s at least a chance the compiler will be able to tell you that you made a mistake; if you explicitly initialise it, then it’s all on you. -George
signature.asc
Description: Message signed with OpenPGP
