From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Eisele Subject: Re: Fwd: dependency tee from c parser entities downto token Date: Thu, 10 May 2012 14:28:23 +0200 Message-ID: <4FABB467.7030703@gmail.com> References: <4F967865.60809@gaisler.com> <4FA5B9E8.7010208@gmail.com> <4FA767BD.8060703@gaisler.com> <4FA8BF7D.60606@gaisler.com> <4FAA3D50.8080901@gaisler.com> <4FAB5DEA.5060009@gaisler.com> <4FAB6268.7070908@gaisler.com> <4FAB8F9E.8040205@gaisler.com> <4FABB132.1070308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-lb0-f174.google.com ([209.85.217.174]:35938 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755267Ab2EJMYr (ORCPT ); Thu, 10 May 2012 08:24:47 -0400 Received: by lbbgm6 with SMTP id gm6so1007304lbb.19 for ; Thu, 10 May 2012 05:24:45 -0700 (PDT) In-Reply-To: <4FABB132.1070308@gmail.com> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Christopher Li Cc: Konrad Eisele , Linux-Sparse >> A change like this is bound to need some careful discussion and >> planing. Yes, I am guilt of only accepting patches meet some subjective >> stander of mine. But so is to any self respect project maintainers. >> I would rather spend some time to do it right than commit some thing >> I would regret later on. > > Do a B(B(x)) and your sym->parent linked-list will fail. > -- Konrad I have to revise my previous assumption though: #define B(y) A(x) B(1) i thought that in the body expansion of B recursion is involved, so that it would yield: expand_macro(A); expand_macro(B); but that was wrong, so its expand_macro(B); expand_macro(A); you might be right here. expand() is flat when substituting the body part of the macro. It might work. -- Konrad > >> >> I heard you that this discussion is taking long. That is why I offer >> to write up the core sparse part of the change myself and let you >> provide feed back to shape it the way we both can happy. >> That is the agreement we have earlier right? >> >> So I did exactly what I said I am going to do, now you are calling >> me my way vs your way? >> >> My evaluation function is straightly technical merit: >> >> - I prefer patch minimize performance impact on other clients don't >> use this feature. >> - I prefer simpler interface over complicate one. >> >> To me, believe it or not, It is never about my way vs your way. >> If you submit a perfect patch, I would more than happy to apply it. >> Apply a patch is much easier than writing one myself. >> >> Chris >> >