From: Floris Kraak <randakar@gmail.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Sam Ravnborg <sam@ravnborg.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Trivial Patch Monkey <trivial@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] Kbuild: Disable the -Wformat-security gcc flag
Date: Fri, 15 May 2009 15:28:18 +0200 [thread overview]
Message-ID: <56e1b5710905150628w912759an21c82efc3fae7f4a@mail.gmail.com> (raw)
In-Reply-To: <84144f020905150323m76cdd775p87abec356e355d37@mail.gmail.com>
On 5/15/09, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> On Wed, Feb 4, 2009 at 5:28 PM, Floris Kraak <randakar@gmail.com> wrote:
> > Some distributions have enabled the gcc flag -Wformat-security by default.*
> > This results in a number of warnings about format arguments to
> > functions, sometimes in cases where fixing the warning is not likely
> > to actually fix a bug.
> > Instead of hand patching a dozens of places (possibly more) that
> > produce warnings that get ignored anyway we just turn off the flag in
> > the Makefile.
> >
>
> Is there a reason this patch was not merged? Yes, it's clearly a
> distro problem but apparently there's no easy way to turn it off.
>
Well, I posted a few follow up patches that turned this one on his
head - instead of disabling the feature in GCC I attempted to hand
patch every location that caused the warning instead.
However, that is quite a large job for fixing a mere 'minor annoyance'
- there are a number of obvious places where merely changing the
definition of a 'char* foo' variable into a 'char foo[]' variable
makes the warning go away (hence easily done)but getting rid of all of
them requires some real code changes here and there. In theory all of
them are harmless but it adds up to well over 130 patches. (When
split.)
I was still in the process of triaging the whole thing into a
mergeable form when some assignment came along that caused me to drop
the whole thing on the floor. I can dig them up and repost them if you
like ;-)
Tellingly enough I didn't find any place where the warning was
actually warning about anything harmful. Maybe I just need better
glasses though ;-)
Quite honestly I still believe just disabling this check is the best
thing to do.
It would be *really* nice if printk could just check instead how many
arguments it has and refrain from parsing the format string if there
aren't any. Unfortunately that's seemingly impossible - or at least,
well beyond my abilities ;-)
Regards,
Floris
---
'Or lawyers may say, “But if I decline, someone else will do it. So
what is gained?” My reply: “Let someone else do it. But not you. Honor
is personal. Worry about yourself. You don’t get a pass from moral
responsibility because you acted for a client.”
That’s the first lesson I would offer, aimed at lawyers. A second
lesson, aimed at all, is this: Keep ready your capacity for outrage.
This is very important. Next to the vote, outrage is the one response
each of us can contribute. Outrage is how honor must confront
dishonor. If we lose the capacity for outrage, we are in serious
trouble. '
--- Stephen Gillers
next prev parent reply other threads:[~2009-05-15 13:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 14:28 Floris Kraak
2009-02-04 22:14 ` Sam Ravnborg
2009-02-04 22:26 ` Roland Dreier
2009-02-04 23:48 ` Robert Hancock
2009-02-05 6:37 ` Roland Dreier
2009-02-05 8:26 ` Floris Kraak
2009-02-05 10:15 ` Floris Kraak
2009-02-05 10:27 ` Andreas Schwab
2009-02-05 10:50 ` Floris Kraak
2009-02-05 21:52 ` Roland Dreier
2009-02-10 21:11 ` Kyle Moffett
2009-02-10 21:56 ` Floris Kraak
2009-02-10 20:24 ` Pavel Machek
2009-02-10 21:48 ` Floris Kraak
2009-05-15 10:23 ` Pekka Enberg
2009-05-15 13:28 ` Floris Kraak [this message]
2009-05-15 20:42 ` Pekka Enberg
2009-05-15 22:09 ` Floris Kraak
2009-06-14 20:50 ` Sam Ravnborg
2009-06-15 5:54 ` Pekka J Enberg
2009-06-15 8:02 ` Floris Kraak
2009-06-26 22:15 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56e1b5710905150628w912759an21c82efc3fae7f4a@mail.gmail.com \
--to=randakar@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=sam@ravnborg.org \
--cc=trivial@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®