[cfe-dev] The %p conversion and cast to void*

[Seth Cantrell]

I'm also concerned about off-by-default warnings, which is one of the reasons my default set of warning flags starts with -Weverything.

I encourage other developers to do the same as part of implementing a 'subtractive' (or 'blacklist') strategy for enabling warnings rather than an 'additive' (or 'whitelist') strategy: Enable everything and then disable just specific warnings if necessary after evaluating them. The value being that you're less likely to miss useful warnings, and when the compiler is updated with new warnings you get made aware of them automatically.

Obviously this is useful for everyday development, rather than for end users just installing programs from a source repository, so release source packages for end users won't use -Weverything -Werror. It's just for developers actively working on a project, and in that use-case it's very nice.

IIRC I originally got the suggestion from an email by Chris Lattner on this list. Since I had good experiences with it I started promoting it, and I've seen some other people saying similar things.

http://www.bignerdranch.com/blog/a-bit-on-warnings/
http://amattn.com/p/better_apps_clang_weverything_or_wall_is_a_lie.html
http://stackoverflow.com/questions/16384530/clang-in-xcode-start-with-weverything-and-manually-disable-particular-warnin
https://news.ycombinator.com/item?id=7282277 <https://news.ycombinator.com/item?id=7282277>


> On Feb 24, 2015, at 1:00 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Feb 24, 2015 at 9:50 AM, Seth Cantrell <seth.cantrell at gmail.com <mailto:seth.cantrell at gmail.com>> wrote:
> It seems reasonable for this kind of warning to go under some -pedantic flag, something like "-Wformat-pedantic".
> 
> Possibly, though there's also a general aversion to adding off-by-default warnings to clang because they end up undertested and a burden on the codebase (in terms of complexity, etc) with relatively little value.
>  
> 
> > On Feb 24, 2015, at 12:31 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
> >
> > On 21 Feb 2015, at 03:56, Rouben Rostamian <rostamian at umbc.edu <mailto:rostamian at umbc.edu>> wrote:
> >>
> >> My question is: Why is it that removing the cast /does not/
> >> trigger a warning in Clang?  Do I need to specify further
> >> compilation flags to get that warning?
> >
> > It used to generate a warning in clang but it was spectacularly annoying and so was removed because it generated a huge number of false positives.  The C standard does require that the argument for %p 'be a pointer to void', but the only platforms where any other data pointer (in the same address space) would be problematic are ones that do not natively support byte addressing and so need different pointer types for char* and void* and anything word aligned.  Clang does not support any such architectures and a lot of C code that people compile with clang / gcc would break on such architectures.
> >
> > The choice is to either have a warning that you are violating the letter of the C spec, but that your code will still work on every platform that you're likely to ever care about (and I say this as someone working on an architecture with a very unusual pointer representation, for which this warning would *still* be a false positive), or to allow this code through.
> >
> > Clang policy is that good code ought to be able to use -Wall -Werror by default, because warnings that have too high a false positive rate are not present.  If warnings are too likely to produce false positives (i.e. flag things that work fine on every system where the code is plausibly likely to run), then it doesn't help the programmer, it just makes them turn off the warning.
> >
> > David
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150224/0f661b7e/attachment.html>