Date: Sat, 26 Apr 2014 07:40:18 +0100 From: Ben Laurie <benl@freebsd.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: "freebsd-security@freebsd.org security" <freebsd-security@freebsd.org> Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <CAG5KPzzQCoHXHrZ2w3dK_XLts2-2uqRqho4n5_cZLVYvS7cQcQ@mail.gmail.com> In-Reply-To: <32377.1398460907@server1.tristatelogic.com> References: <CAG5KPzw_cOfFLX_kn=5DWAX%2Bz%2B9VeXuzo3Q8YekDJG37tDQ_wQ@mail.gmail.com> <32377.1398460907@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 April 2014 22:21, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: > > In message <CAG5KPzw_cOfFLX_kn=5DWAX+z+9VeXuzo3Q8YekDJG37tDQ_wQ@mail.gmail.com> > Ben Laurie <benl@freebsd.org> wrote: > >>But that would then hide the error condition of it being not set to a >>new value after initialisation. > > The (modified/quieted) code example under discussion is as follows: > > variable = value0; /* initialization */ > if (condition) variable = value1; > if (!condition) variable = value2; > use (variable); > > Please note that variable *is* *always* set to some value (either value1 > or value2) after initialization. The "error condition" that you seem > concerned about having explicitly flagged does not in fact exist in the > example code snippet under discussion. Of course it doesn't, that's the whole point. >>One better answer would be to have a way to annotate that after the >>two conditionals you assert that |variable| is initialised. Then a >>future, smarter static analyzer can attempt to prove you wrong. > > Sir, is there any sense in which the final line of the above example > _does not_ already and standing all by itself constitute an implicit > assertion that "variable" has been initialized by that point in the > code? My point is that if you want to silence the warning, the right way to do it is by saying "you are wrong, here is my claimed truth" rather than by changing the code to avoid the shortcoming in analysis. The reason being that future analysis can decide to ignore or disprove your assertion, but cannot ignore the suppression you suggest.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5KPzzQCoHXHrZ2w3dK_XLts2-2uqRqho4n5_cZLVYvS7cQcQ>