Agreed.  We could even have -Wformat-gnu on by default for certain targets 
where the GNU extensions were known to be supported. 

There is a larger issue, however, that some format specifiers may only make 
sense for certain functions and not others, even on the same target.  Having a 
separate warning flag doesn't actually help here.  Instead, we need a way to 
distinguish functions by the grouping of format specifiers that they accept.  I 
don't have clear design in my head on how to do this, either than extending the 
existing 'format' attributes. 


On Tuesday, January 24, 2012 at 3:43 PM, Chandler Carruth wrote:

> If you would like to contribute a -Wformat-gnu set of warnings which flag use 
> of format specifiers that are GNU extensions, I think that would be a very 
> useful warning for Clang to have.
> 
> On Tue, Jan 24, 2012 at 3:15 PM, Joerg Sonnenberger <[email protected] 
> (mailto:[email protected])> wrote:
> > The problem is that it is about shutting up warnings for Linux (or OSX)
> > specific code and at the same time stopping the warning for everyone
> > else on code that needs them.
> We can't have it both ways though. We have to pick one behavior to be the 
> default, and currently the largest users of Clang are on OSX or Linux and 
> thus benefit from the default behavior you are observing. It's not a great 
> way to choose a default, but neither is making warn by default for the 
> majority of its users on code that is correct. =/ Again, I'm not really 
> thrilled about it, but it seems pragmatic. It is at least consistent with 
> -Wgnu and other extensions in Clang. 
> 
> I don't think its too onerous to have to pass -Wformat-gnu to get more 
> detailed warnings, any more than some folks pass -Wgnu to find out about 
> language extensions in use.
> 
> While it might be possible to make -Wformat include -Wformat-gnu when not 
> compiling in one af the '-std=gnu*' language dialect variations, that would 
> seem a really confusing bit of behavior. I like warning flags being simple 
> set arithmetic. 
> _______________________________________________
> cfe-commits mailing list
> [email protected] (mailto:[email protected])
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to