[cfe-commits] [Patch] Warn about non-standard format strings (PR12017)

[Ted Kremenek]

On Feb 20, 2012, at 12:21 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:

>> There's "non-standard" and then there's completely unportable.  Warnings like:
>> 
>> +  // Combining 'L' with an integer conversion specifier.
>> +  printf("%Li", (long long)42); // expected-warning{{using the length modifier 'L' with the conversion specifier 'i' is non-standard}}
>> +  printf("%Lo", (long long)42); // expected-warning{{using the length modifier 'L' with the conversion specifier 'o' is non-standard}}
>> 
>> are likely going to just irritate people.  What's the value in that?
> 
> What is that supposed to mean?

AFAIK, it means nothing.  My brain segfaulted.  I was thinking of something else.

> From looking at analyze_format_string,
> that should give a warning because (a) L doesn't make sense for integers
> and (b) because the argument isn't int. Or do you mean the Microsoft
> extension for dealing with 64bit integers? Note that this is part of the
> reason why silently accepting them is bad -- I need to have a printf(3)
> man page for the platform you had in mind when writing this code to even
> understand what it is really supposed to do.


Do we really silently accept them?  Until very recently (a month ago?), we emitted:
	

t.c:4:12: warning: length modifier 'L' results in undefined behavior or no
      effect with 'i' conversion specifier [-Wformat]
  printf("%Li", (long long) 2);
          ~^~
1 warning generated.


Now I see that TOT doesn't warn here.  Is this accepted somewhere?  I see no test cases in clang/test that shows we should accept this.  Was this an intentional change, or a regression?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120220/cfffa70a/attachment.html>