Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/

From: Tijl Coosemans <tijl_at_coosemans.org>
Date: Thu, 6 Jan 2011 20:56:49 +0100
On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote:
> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker:
>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote:
>>> On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote:
>>>> These are all marked as __dead2, so the compiler should "know" that these do
>>>> not return.
>>> 
>>> And clang did the right thing here in the past. Beware that it does no
>>> inter-procedural analysis yet, so it will usually miss that usage()
>>> calls exit unconditionally.
>>> 
>>> *But*, it should grok that for err(3) and exit(3). Now there are some
>>> possible remedies:
>>> 
>>> - get IPA to work with clang, or at least file a bug
>>> - mark functions as __dead2 (please don't do that)
>> 
>> Why not?
> 
> Because the analyzer is supposed to find bugs. Only the function that
> really doesn't return should be marked as such. If we begin spewing
> __dead2's everywhere, it's bound to silence a valid bug somewhere
> down the line when e.g. a conditional in a print_help() function is
> changed subtly so it doesn't always reach exit().

On the other hand you can't really expect the compiler/analyser to know
what a procedure in another file does, so in that case you need __dead2
anyway. For procedures in the same file it would be nice if the compiler
automatically optimised non-returning calls, but I'm not sure the
analyser should do that. If the code relies on the fact that a procedure
doesn't return, which is the case here, it's a good thing to declare it
as such exactly to prevent bugs from creeping in. You can't add a return
statement to a non-returning procedure without the compiler complaining
about it and I'm sure the analyser would complain about it as well. So
you won't be hiding other bugs by adding __dead2 here and there.

Received on Thu Jan 06 2011 - 19:26:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC