linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).