From patchwork Thu Mar 19 22:09:06 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Al Viro X-Patchwork-Id: 13167 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2JM9YMf026579 for ; Thu, 19 Mar 2009 22:09:35 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753081AbZCSWJL (ORCPT ); Thu, 19 Mar 2009 18:09:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758423AbZCSWJK (ORCPT ); Thu, 19 Mar 2009 18:09:10 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:33013 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753081AbZCSWJJ (ORCPT ); Thu, 19 Mar 2009 18:09:09 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.69 #1 (Red Hat Linux)) id 1LkQQE-0002ry-HB; Thu, 19 Mar 2009 22:09:06 +0000 Date: Thu, 19 Mar 2009 22:09:06 +0000 From: Al Viro To: Christopher Li Cc: Hannes Eder , linux-sparse@vger.kernel.org, Nicholas Mc Guire Subject: Re: [bug, bisected, -chrisl] Segfault at evaluate.c:341 Message-ID: <20090319220906.GG28946@ZenIV.linux.org.uk> References: <154e089b0903190649k7f099c93qedf6eb8e6a1c0a86@mail.gmail.com> <20090319144622.GA28946@ZenIV.linux.org.uk> <154e089b0903191138x15b66808v70bc862d7a13e3c2@mail.gmail.com> <20090319191431.GD28946@ZenIV.linux.org.uk> <70318cbf0903191304k1fefe9afkb4be21550d8f9abe@mail.gmail.com> <20090319215250.GF28946@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090319215250.GF28946@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org On Thu, Mar 19, 2009 at 09:52:50PM +0000, Al Viro wrote: > On Thu, Mar 19, 2009 at 01:04:20PM -0700, Christopher Li wrote: > > > We should stop the segfault though. I take a look at it. It seems that > > there is a SYM_NODE with base_type is NULL. I guess in some of > > the error path we result in an invalid AST three. > > We are getting some mess with K&R declarations. Which is bloody likely > to be my fault; will check. Yeah... It's an old b0rken handling of calls for K&R + changes that exposed that even worse. Status quo is restored by the patch below, but it's a stopgap - e.g. void f(); void g(void) { f(0, 0); } will warn about extra arguments as if we had void f(void); as sparse had been doing all along. B0rken. Testcase for the segfault is void f(x, y); void g(void) { f(0, 0); } Signed-off-by: Al Viro --- -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/parse.c b/parse.c index b9b96ba..87f6264 100644 --- a/parse.c +++ b/parse.c @@ -2323,6 +2323,7 @@ static struct token *identifier_list(struct token *token, struct symbol *fn) sym->ident = token->ident; token = token->next; sym->endpos = token->pos; + sym->ctype.base_type = &incomplete_ctype; add_symbol(list, sym); if (!match_op(token, ',') || token_type(token->next) != TOKEN_IDENT ||