From: Ingo Molnar <mingo@elte.hu>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
Stephen Rothwell <sfr@canb.auug.org.au>, mingo <mingo@redhat.com>,
tglx <tglx@linutronix.de>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: Tree for April 10 (arch/x86)
Date: Mon, 14 Apr 2008 10:34:40 +0200 [thread overview]
Message-ID: <20080414083440.GD19865@elte.hu> (raw)
In-Reply-To: <20080414082220.GZ9785@ZenIV.linux.org.uk>
* Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Mon, Apr 14, 2008 at 10:12:20AM +0200, Ingo Molnar wrote:
>
> > well, gcc does not "recover", we _gave_ it the format string as a
> > constant, and do so in 99.9% of the cases. It is a totally
> > well-specified thing.
>
> It is an undefined behaviour according to any variant of C standard.
> Sorry, printf() is not magic and it does _not_ have special calling
> conventions.
... but reality called in and gcc added printf format checks as a gcc
extension and even modifies the code to make it safe when the user gets
it "wrong".
why? Because vararg is a dangerous concept as specified and strong but
meaningful type checking should be enforced across such places. And our
goal is to build better software and avoid bugs that can be avoided, not
to follow standards where they are _stupid_.
> What is not right is the lack of ability to define new conversions.
> If we could do that, we would kill the absolute majority of casts -
> and remain within normal C limits...
sure. I dont actually care that much how it's solved - via extending the
concept of varargs or via working it around where it hurts most. What
matters is that the current situation is suboptimal. The present
"solution" uglifies the code and more ugly code is always more
dangerous.
But it's even worse: bogus warnings also reduce the psychological
threshold to adding stupid casts - if you have to add casts in a printk
that looks senseless then why not circumvent _other_ warnings that look
senseless?
Excessive false positives are actively harmful to software quality
because they teach people to ignore warnings.
Ingo
next prev parent reply other threads:[~2008-04-14 8:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-10 8:14 linux-next: Tree for April 10 Stephen Rothwell
2008-04-10 10:24 ` [BUG] linux-next: Tree for April 10 - kernel panic while loading ata driver on powermac Kamalesh Babulal
2008-04-10 10:45 ` Jeff Garzik
2008-04-10 11:02 ` Kamalesh Babulal
2008-04-10 11:32 ` Alan Cox
2008-04-10 12:14 ` Jeff Garzik
2008-04-10 12:03 ` Bartlomiej Zolnierkiewicz
2008-04-10 17:14 ` Bartlomiej Zolnierkiewicz
2008-04-10 18:25 ` Kamalesh Babulal
2008-04-10 19:16 ` Bartlomiej Zolnierkiewicz
2008-04-10 17:42 ` linux-next: Tree for April 10 Greg KH
2008-04-10 18:07 ` [BUG] linux-next: April 10 - kernel oops at kmem_cache_alloc () regression from April 9 kernel Kamalesh Babulal
2008-04-11 17:56 ` Suresh Siddha
2008-04-14 13:14 ` Kamalesh Babulal
2008-04-10 19:34 ` linux-next: Tree for April 10: generic pci_enable_resources() strikes again Mariusz Kozlowski
2008-04-14 1:48 ` Stephen Rothwell
2008-04-14 4:28 ` Greg KH
2008-04-14 4:49 ` Stephen Rothwell
2008-04-10 22:07 ` linux-next: Tree for April 10 (ftrace) Randy Dunlap
2008-04-10 22:09 ` linux-next: Tree for April 10 (arch/x86) Randy Dunlap
2008-04-11 7:46 ` Ingo Molnar
2008-04-11 15:19 ` Randy Dunlap
2008-04-11 15:26 ` Al Viro
2008-04-14 8:12 ` Ingo Molnar
2008-04-14 8:22 ` Al Viro
2008-04-14 8:34 ` Ingo Molnar [this message]
2008-04-14 8:43 ` Jakub Jelinek
2008-04-14 9:30 ` Al Viro
2008-04-14 9:37 ` David Miller
2008-04-14 8:40 ` Jakub Jelinek
2008-04-14 22:28 ` Randy Dunlap
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=20080414083440.GD19865@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=randy.dunlap@oracle.com \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.