Linux SPARSE checker discussions
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsayjones.plus.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: make selfcheck
Date: Tue, 18 Jul 2017 17:52:53 +0100	[thread overview]
Message-ID: <f9db8db5-ca7d-d83d-fa65-182d8b61f773@ramsayjones.plus.com> (raw)
In-Reply-To: <CANeU7Q=7=w6WhCkg=KNfLOy5HMGizgO46zh+M_D6mK8AOASnNg@mail.gmail.com>



On 18/07/17 13:53, Christopher Li wrote:
> On Mon, Jul 17, 2017 at 3:28 PM, Ramsay Jones
> <ramsay@ramsayjones.plus.com> wrote:
>>
>> I nearly have a clean 'make selfcheck' (I suspect you do too!).
>> I was supposed to have gone out a while ago, ... I guess I will
>> not get it finished before I go. :(
> 
> I have send out a V2 version of the patch.
> 
> BTW, I think most of the macro define part of the cgcc should be move to sparse
> as well. In the end, cgcc can be merge with sparse as one. I think
> even with all those
> macro used by user space program, it shouldn't impact the kernel compile, right?

Hmm, I don't think cgcc should be merged into sparse completely no.
Some things from cgcc could be moved into sparse, but not everything.
One of the main uses of cgcc is as a proxy for (g)cc. (Yes, that could
also be moved into sparse, but why bother?)

I still have the 'intptr_t' and 'int32_t' warnings on cygwin, which I
could solve either in cgcc or sparse (I was leaning in the direction
of sparse, because Luc has already added some of these macros). These
definitions would not cause any problems on the kernel (well, if they
did, it would also be a problem with gcc!).

However, I would not like to say whether some of the 'platform user
space' macros would cause a problem on the kernel or not. The only
way to know is to give it a try! (Unfortunately, due to lack of disk
space, I have deleted my kernel git repository). :(

ATB,
Ramsay Jones


  reply	other threads:[~2017-07-18 16:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 16:30 make selfcheck Ramsay Jones
2017-07-17 18:19 ` Ramsay Jones
2017-07-17 19:16   ` Christopher Li
2017-07-17 19:28     ` Ramsay Jones
2017-07-18 12:53       ` Christopher Li
2017-07-18 16:52         ` Ramsay Jones [this message]
2017-07-18 17:04           ` 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=f9db8db5-ca7d-d83d-fa65-182d8b61f773@ramsayjones.plus.com \
    --to=ramsay@ramsayjones.plus.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --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