From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luc Van Oostenryck Subject: Re: [PATCH 2/4] Add support for show_data() Date: Wed, 4 Feb 2015 01:50:25 +0100 Message-ID: <20150204005025.GB8867@macbook.lan> References: <1422757186-8007-1-git-send-email-luc.vanoostenryck@gmail.com> <1422757186-8007-3-git-send-email-luc.vanoostenryck@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-wg0-f45.google.com ([74.125.82.45]:55677 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754605AbbBDAua (ORCPT ); Tue, 3 Feb 2015 19:50:30 -0500 Received: by mail-wg0-f45.google.com with SMTP id x12so47636544wgg.4 for ; Tue, 03 Feb 2015 16:50:29 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Christopher Li Cc: Linux-Sparse , Rasmus Villemoes 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 > 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