[cfe-dev] RFC: Enable nonnull and warn_unused_result attributes by default

[Douglas Gregor]

On Jun 26, 2012, at 7:15 PM, Timo Sirainen <tss at iki.fi> wrote:

> On 27.6.2012, at 5.00, John McCall wrote:
> 
>> On Jun 26, 2012, at 2:53 PM, Timo Sirainen wrote:
>>> GCC has "nonnull" and "warn_unused_result" attributes that are really great for finding bugs, assuming they're used everywhere. The problem is, they would have to be used for >99% of the functions, which makes them way too much trouble to be worth it for normal code. So wouldn't it be better to just make that the default behavior, and add "null" and "nowarn_unused_result" attributes for the few exceptions where the opposite behavior is needed?
>> 
>> Maybe you're very disciplined about this, but legally null parameters are pervasive in many C code bases.  There is no way we could create such a warning and enable it by default;  our users would hate us.
>> 
>> Functions with results that are typically ignored are less common but still quite idiomatic.  This warning would be possible, but it'd take a lot of tweaking.
> 
> I didn't mean that clang would enable these by default for all users. I meant adding a new clang parameter that can be used to optionally enable them for all functions in that code base. That wouldn't cause any trouble for existing users, but would be very helpful for me and maybe for others.
> 
> I've already implemented these to both clang and to my 300k line code base (http://hg.dovecot.org/dovecot-2.2/). I get zero warnings with them enabled, so it's definitely something that can be very useful for code bases that are disciplined enough.


The problem here is that *very* few users care to be this disciplined. Among those who care, for many users it isn't even possible: most applications include a number of third-party headers that would certainly not have the appropriate annotations, and which can't realistically be updated to have all of these annotations. 

It's clear that this will never be a "default-on" warning, and because the potential user base is not small, I also don't think that it should go into the main Clang tree at all.

	- Doug