Bug 60287 - Various issues on -Wformat=
Summary: Various issues on -Wformat=
Status: RESOLVED DUPLICATE of bug 52952
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-20 09:07 UTC by Chengnian Sun
Modified: 2014-02-20 21:42 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chengnian Sun 2014-02-20 09:07:01 UTC
1) Besides "-Wformat=2", gcc accepts any option in the form of -Wformat=<number>
   Based on the manual, gcc only accepts "-Wformat=2", and others such as "-Wformat=0,1, 3-9" should be invalid. Any undocumented behavior?



2) Is the warning name "[-Wformat=]" in the warning message intended? 

$: gcc-trunk -Wformat=3 s.c
s.c: In function ‘main’:
s.c:4:3: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘int’ [-Wformat=]
   printf("%s%s", i, i);
   ^
s.c:4:3: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
$:
 

3) Is the column number information correct in the warning message? Should the warning refer to the location of the problematic argument, or the function call? Currently clang warns at the argument. 

$: clang-trunk -Wall s.c
s.c:4:18: warning: format specifies type 'char *' but the argument has type 'int' [-Wformat]
  printf("%s%s", i, i);
          ~~     ^
          %d
s.c:4:21: warning: format specifies type 'char *' but the argument has type 'int' [-Wformat]
  printf("%s%s", i, i);
            ~~      ^
            %d
2 warnings generated.
$
Comment 1 Tobias Burnus 2014-02-20 09:59:02 UTC
(In reply to Chengnian Sun from comment #0)
> 1) Besides "-Wformat=2", gcc accepts any option in the form of
> -Wformat=<number>
>    Based on the manual, gcc only accepts "-Wformat=2", and others such as
> "-Wformat=0,1, 3-9" should be invalid. Any undocumented behavior?


Well, -Wformat=0 disables all format warnings (not really documented) - and should be equivalent to -Wno-format; "-Wformat=1" is equivalent to "-Wformat" - and that is explicitly documented in the manual: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-294

And -Wformat=2 is equivalent to -Wformat=1 plus additional warnings.

-Wformat=3 would be equivalent to -Wformat=2 plus additional (nonexisting) options. And I think it currently acts as -Wformat=2, which should be fine as well.

(Similar is: -O0, -O1, -O2, -O3; where some other compilers have -O4 - but GCC doesn't and [I think it] treats it as -O3.)


> 2) Is the warning name "[-Wformat=]" in the warning message intended? 

Yes - as one doesn't want to distinguish between "-Wformat=2" and "-Wformat/-Wformat=1 -Wformat-security". In particular, "-Wformat-security" requires "-Wformat=1" in addition, otherwise, it doesn't warn at all.

Thus, printing [-Wformat=] is way easier than to re-construct the exact option.




> 3) Is the column number information correct in the warning message? Should
> the warning refer to the location of the problematic argument, or the
> function call?

Well, the column number is correct - but pointing to either to the proper '%' in the format string or to the argument would be better. - Like always, there is room for improvement.
Comment 2 Manuel López-Ibáñez 2014-02-20 12:05:11 UTC
Just adding a bit more info:

1) Like Tobias said, it is intended.
2) I agree that reproducing the exact flags that trigger the warning would be useful, but it is a lot of work that nobody so far found time to address. It seems also quite low priority compared to other things.

3) is PR52952, so I am closing this as a duplicate of that. I did some work, but then I got stuck. I don't have enough free time anymore to continue it, so if someone wishes to pick it up, please do so.

*** This bug has been marked as a duplicate of bug 52952 ***
Comment 3 Chengnian Sun 2014-02-20 21:42:39 UTC
Thanks, Tobias and Manuel.