FYI: clang static analyzer page has moved to
tijl at coosemans.org
Thu Jan 6 20:26:17 UTC 2011
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110106/2471ca34/attachment.pgp
More information about the freebsd-current