[cfe-commits] r145697 - in /cfe/trunk: include/clang/Analysis/Analyses/FormatString.h lib/Analysis/FormatString.cpp lib/Analysis/PrintfFormatString.cpp lib/Sema/SemaChecking.cpp test/Sema/format-strings-int-typedefs.c

Hans Wennborg hans at chromium.org
Mon Dec 5 05:45:45 PST 2011


On Sun, Dec 4, 2011 at 4:55 AM, John McCall <rjmccall at apple.com> wrote:
> On Dec 3, 2011, at 1:37 PM, Joerg Sonnenberger wrote:
>> On Sat, Dec 03, 2011 at 10:14:24AM -0800, Douglas Gregor wrote:
>>> The warning does need to find the typedef, because it shouldn't suggest
>>> 'size_t' if no 'size_t' is visible. However, you can just perform
>>> lookup into the translation unit (using DeclContext's lookup) to find
>>> an appropriately-typed 'size_t' typedef.
>>
>> I disagree on this. %zu should *always* suggest size_t, %ju should
>> *always* suggest uintmax_t etc.
>
> I agree, although I also agree that suggesting a type not in scope is
> not great.  We could check for the type and suggest the C99 header to
> #include if it's not present, though.

After thinking more about this, I think always suggesting size_t is
the best thing to do, whether size_t is in scope or not.

Suggesting it when it's not defined is not great, but I'm not sure
it's actually that bad either? Making the warning suggest including
headers, etc. sounds like it could get pretty verbose, especially
since the correct fix for the code might rather be to change the
format specification.

One thing we should do is to catch incompatible declarations of size_t
and issue warnings like "incompatible redeclaration of library type
%0", but that's a separate issue.

 - Hans




More information about the cfe-commits mailing list