[cfe-commits] r148859 - in /cfe/trunk: lib/Analysis/FormatString.cpp lib/Analysis/PrintfFormatString.cpp lib/Analysis/ScanfFormatString.cpp test/Sema/format-strings-scanf.c test/Sema/format-strings.c

[Joerg Sonnenberger]

On Tue, Jan 24, 2012 at 03:03:56PM -0800, Chandler Carruth wrote:
> On Tue, Jan 24, 2012 at 1:48 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> > wrote:
> 
> > On Tue, Jan 24, 2012 at 09:29:54PM -0000, Ted Kremenek wrote:
> > > URL: http://llvm.org/viewvc/llvm-project?rev=148859&view=rev
> > > Log:
> > > Teach scanf/printf checking about '%Ld' and friends (a GNU extension).
> >  Fixes PR 9466.
> >
> > Can we please stop adding GNU extensions for scanf/printf until they have
> > a proper options to request them?
> 
> 
> I don't understand, what options do you want?
> 
> If you would like some ability to enforce strictness, I think ext-warn and
> other such diagnostics for use of extensions might be an option. Propose an
> actual feature with patches?

-Wformat should ensure that the code uses correct format strings.
Recognizing glibc extensions is fine, but should *not* be the default,
since people will depend on them to work and wonder when they get
crashes or undefined behavior. A good example for why this is important
is %m -- it is valid for syslog(3), but an unportable extension for
printf(3). Guess what -- everyone copied GCC's behavior and there is no
separation between the two format string checks. I'm not even going into
the various "allocate memory" modifiers for scanf.

> > At the moment, I consider this more
> > harmful than complaining about them unconditionally.
> >
> 
> Clang does aim for compatibility, and this is nothing new. I think it is
> very reasonable for folks to get Clang to not warn on correctly behaving
> code.

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.

Joerg