[cfe-commits] [Patch] Format string warnings should refer to "%zu" etc by typedef type

[David Blaikie]

On Fri, Dec 2, 2011 at 12:42 PM, Hans Wennborg <hans at chromium.org> wrote:
> On Fri, Dec 2, 2011 at 7:43 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> This raises a question: Ideally this diagnostic should:
>>
>> a) verify that the type used for the parameter to printf is actually
>> size_t, not unsigned int, for example
>
> I suppose that depends how strict we want to be. If the type of size_t
> on the platform is unsigned int, then the programmer isn't technically
> doing anything wrong to pass such an argument for "%zu", though it
> certainly isn't portable.

Indeed - perhaps a different level of warning, I don't know - in that
case they /should/ be using the format specifier for unsigned int, not
size_t.

> And what if the programmer has introduced their own "typedef size_t
> my_size_type", should that be ok? Or "typedef __typeof(sizeof(int))
> my_size_type" ?

We can potentially check some of those errors, but we already, for
example, assume that NULL is /the/ NULL macro, not any user-defined
garbage. I don't think it would be entirely unrealistic to assume that
size_t is the same.

>> b) shouldn't mention the underlying type, only the typedef - since
>> that's what the format specifier is for.
>
> The problem is what it should do when the typedef isn't available (or
> worse, typedeffed to the wrong type).

I'd still suggest it even if the typedef isn't available (in fact
there's no suggestion, simply the statement that "the argument you're
passing isn't of type size_t") - though you're right, there are some
interesting cases. decltype(sizeof(...)) (basically what you showed)
could be tricky, because it's only a typedef it's unverifiable.

> I'm not sure what the best thing to do is, but I think my patch made
> it slightly better than it was before :)

Agreed.
- David