Bug 1025300 - include "-Wformat-security" in "-Wall" (RFE)
include "-Wformat-security" in "-Wall" (RFE)
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-31 08:36 EDT by Dhiru Kholia
Modified: 2014-03-24 23:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-31 08:45:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dhiru Kholia 2013-10-31 08:36:00 EDT
It would be great if "-Wformat-security" could be included in "-Wall".

For more details, please see https://fedorahosted.org/fesco/ticket/1185 URL.
Comment 1 Jakub Jelinek 2013-10-31 08:45:26 EDT
I certainly don't want to diverge from upstream meaning of -Wall, the set of warnings enabled by default resp. in -Wall resp. in -W shouldn't change through vendor adjustments, if some project using -Werror takes time to ensure it is error (warning promoted to errors) free for some GCC x.y version, if various vendor GCC versions would diverge that, it would be a nightmare for developers.
If you want -Wformat-security for Fedora, just set it in $RPM_OPT_FLAGS.
Comment 2 Bill Nottingham 2013-10-31 11:32:00 EDT
... is there a reason it can't be proposed as an upstream change?
Comment 3 Jakub Jelinek 2013-10-31 11:38:15 EDT
It isn't a warning without small rate of false positives, I'd categorize it more as a coding style warning, so I personally don't think it is a good idea to include it in -Wall and thus perhaps am not the right person to champion such a change.  Anyone who thinks there are sufficient arguments for that can surely propose it in http://gcc.gnu.org/bugzilla/, though there is less than a month before new features won't be accepted anymore for 4.9.
Comment 4 Jakub Jelinek 2013-10-31 11:40:18 EDT
Note, -D_FORTIFY_SOURCE (not even =1) isn't on by default either, and the most dangerous thing that would result from user controlled strings being passed to *printf family of function is %n, which is blocked already by -D_FORTIFY_SOURCE=2.
Comment 5 Stephen Gallagher 2013-11-06 13:08:49 EST
If we don't include it in -Wall, could we at least argue for inclusion in -Wextra?
Comment 6 Jakub Jelinek 2013-11-06 13:11:26 EST
That is the same thing.

Note You need to log in before you can comment on or make changes to this bug.