[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1178089444.28659.246.camel@localhost.localdomain>
Date: Wed, 02 May 2007 17:04:04 +1000
From: Rusty Russell <rusty@...tcorp.com.au>
To: David Rientjes <rientjes@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] compiler: define __attribute_unused__
On Tue, 2007-05-01 at 23:41 -0700, David Rientjes wrote:
> On Wed, 2 May 2007, Rusty Russell wrote:
>
> > OTOH, your point about "__unneeded" is well taken. "__needed" and
> > "__optional" perhaps? But their feature is *exactly* that the don't
> > look like the gcc attributes, hence avoid their semantic screwage.
> >
>
> Hmm, __optional doesn't sound appropriate either. Since this is going to
> be defined to be __attribute__ ((unused)), it can apply to both functions
> and variables. It should be applied to a function if it truly is
> unreferenced within the tree (and there are several examples of this
> current HEAD) and we don't want to use __needed because it still emits the
> function code even though it suppresses the warning. So saying a function
> that has no callers is "__optional" makes no sense since its code isn't
> going to be emitted in gcc >=3.4.
Hi David,
That sounds exactly right to me! If the author says it's optional, it
might be discarded. If they say it's needed, it won't be. At least,
when I'm coding and gcc warns me something is unused, this is the
decision I have to make ("is this really needed or not?").
> What's your opinion of my __needed and __maybe_unused idea such as the
> following?
You mean __used and __maybe_unused? I still think there's a gap between
what the author wants to say ("No, you really have to keep this!" or
"OK, this might not be necessary") and the concept of "used" and
"unused".
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists