linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH 2/4] Add support for show_data()
Date: Wed, 4 Feb 2015 01:50:25 +0100	[thread overview]
Message-ID: <20150204005025.GB8867@macbook.lan> (raw)
In-Reply-To: <CANeU7Qkp-6KbTFgxe1Rvrpud66dB+J+-2XpjVDCwqkNDg4H37Q@mail.gmail.com>

On Sun, Feb 01, 2015 at 09:30:44PM -0800, Christopher Li wrote:
> On Sat, Jan 31, 2015 at 6:19 PM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> > The purpose of show_data() is to visualize data, more or less
> 
> I think show_data() is a bad name. Data is very generic term,
> it has not specific meaning what exactly is that data.
> 
> What you really want to show is the initializer expression.
> Make the function name reflect that.

Yes, the name is too generic. The purpose was to use 'data'
in opposition to 'code'.
 
> > diff --git a/linearize.c b/linearize.c
> 
> Why is this function belongs to linearize.c?
> It has nothing to do with linearization instruction. It has
> every thing to do with the AST structure.
> 
> I suggest that move this code to show-parse.c.
> There are many functions showing internal of the AST
> there.

Well, I put it in linearize because it's where show_entry() is defined
and since I wanted this new show function be its complement, it seemed
to me much better to put it there than in show-parse.c
Even more so because I'm not interested in showing anything close to the AST,
on the contrary, I want to show the values like you would find them in
an assembler code file generated by a compiler after constant folding,
string expansion, type coercion, ...

Anyway, my intention was not to have it included as is (mainly because it's
not complete) but only as a quick tool to investigate the bug that Rasmus have reported.
I'll try to complete it and resubmit it then, taking your remarks in account.


Regards,
Luc

  reply	other threads:[~2015-02-04  0:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30 22:16 Bad interaction between macro expansion and literal concatenation Rasmus Villemoes
2015-01-31  1:23 ` [PATCH] Avoid reuse of string buffer when concatening adjacent string litterals Luc Van Oostenryck
2015-02-03 22:38   ` Rasmus Villemoes
2015-02-04  0:32     ` Luc Van Oostenryck
2015-02-04  3:26       ` Christopher Li
2015-02-04  8:39       ` Rasmus Villemoes
2015-02-04  8:58         ` Rasmus Villemoes
2015-02-04 16:20           ` Christopher Li
2015-02-06 21:52             ` Rasmus Villemoes
2015-02-07  1:30               ` Christopher Li
2015-02-09 21:48                 ` Damien Lespiau
2015-02-04  2:01     ` [PATCH v2] Avoid reusing string buffer when doing string expansion Luc Van Oostenryck
2015-02-04  5:30       ` Christopher Li
2015-02-04  6:22         ` Luc Van Oostenryck
2015-02-04  8:01           ` Christopher Li
2015-02-04 16:38             ` Christopher Li
2015-02-04 23:38               ` Luc Van Oostenryck
2015-02-06 13:58                 ` Christopher Li
2015-02-06 20:32                   ` Rasmus Villemoes
2015-02-04 23:38             ` Luc Van Oostenryck
2015-01-31  5:16 ` Bad interaction between macro expansion and literal concatenation Christopher Li
2015-02-01  2:19   ` [PATCH 0/4] Teach sparse to display data/initial values Luc Van Oostenryck
2015-02-01  2:19     ` [PATCH 1/4] Add support for '-vdata', the equivalent of '-ventry' but for data Luc Van Oostenryck
2015-02-01  2:19     ` [PATCH 2/4] Add support for show_data() Luc Van Oostenryck
2015-02-02  5:30       ` Christopher Li
2015-02-04  0:50         ` Luc Van Oostenryck [this message]
2015-02-01  2:19     ` [PATCH 3/4] Teach sparse to display data/initial values Luc Van Oostenryck
2015-02-01  2:19     ` [PATCH 4/4] Small test/exemple for using '-vdata' Luc Van Oostenryck

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=20150204005025.GB8867@macbook.lan \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --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).