From: Kamil Dudka <kdudka@redhat.com>
To: Christopher Li <sparse@chrisli.org>
Cc: sparse <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH] make sparse headers self-compilable...
Date: Tue, 11 Aug 2009 12:40:06 +0200 [thread overview]
Message-ID: <200908111240.06529.kdudka@redhat.com> (raw)
In-Reply-To: <200908111155.19586.kdudka@redhat.com>
On Tuesday 11 of August 2009 11:55:19 Kamil Dudka wrote:
> On Tuesday 11 of August 2009 11:40:45 Christopher Li wrote:
> > What is the significant of making every header file self compilable?
> > Unlike the kernel header files exported to user space, which usually
> > have self contained meaning. Most of these header file have tight
> > interaction with each other. I don't think it make sense for other sparse
> > application to just use one of the header file.
> >
> > Enforcing each header file to be self compilable will result in a lot
> > of unnecessary include. Gcc needs to include "symbol.h" many times
> > just to skip over it. Take a look at pre-process.c. It is not exactly
> > trivial. It needs to scan the token to find out the end of the if
> > scope. In this case, it might be better just let other header
> > file depend on "symbol.h".
I agree processing of multiple-includes could be painful for the SPARSE
preprocessor. But you don't solve it by avoiding multiple-includes in the
SPARSE code itself. If you want to pass the SPARSE code through SPARSE, it's
small enough to not bother us with performance.
But you have absolutely no control of the foreign code processed by SPARSE
and there the performance impact could be significant. I think this is the
way to go:
http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html
Kamil
next prev parent reply other threads:[~2009-08-11 12:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 20:27 [PATCH] make sparse headers self-compilable Kamil Dudka
2009-08-08 11:10 ` Kamil Dudka
2009-08-11 9:40 ` Christopher Li
2009-08-11 9:55 ` Kamil Dudka
2009-08-11 10:40 ` Kamil Dudka [this message]
2009-08-11 21:08 ` Christopher Li
2009-08-11 21:25 ` Kamil Dudka
2009-08-11 12:48 ` Hannes Eder
2009-08-11 12:59 ` Kamil Dudka
2009-08-11 21:08 ` Christopher Li
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=200908111240.06529.kdudka@redhat.com \
--to=kdudka@redhat.com \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.org \
/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;
as well as URLs for NNTP newsgroup(s).