On Wed, Apr 14, 2010 at 06:02:29PM +0200, Jim Meyering wrote: > I've been running clang regularly, and there have been a few > pesky false-positives that just won't go away. > It's not productive to reexamine them each time, so I've wanted > a way to educate clang without polluting the code with work-arounds > that we'll be stuck maintaining and asking questions about long > after clang becomes smart enough that those work-arounds are no > longer required. > > My solution is to mark the work-arounds with a new macro, sa_assert > (for "static analysis assert"), which acts just like the classical > "assert", but is only enabled when compiled by a static analyzer > like clang or coverity. The advantage of using an assert-like > macro is that people already know that it must have no side-effects > and that will make it easy to remove later, when clang grows up. > > One question you may ask is why add a new symbol, when > "assert" itself can already do this via NDEBUG (defined, any > assertions are disabled, not defined, they are enabled). > There are a few assertions in the code now, and I prefer > not to touch them, and to make it clear that these are > helping us cater to static analyzers. This sounds like a good compromise solution to me Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list