On Feb 20, 2012, at 12:21 PM, Joerg Sonnenberger <[email protected]>
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?
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits