From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26259 invoked by alias); 14 Mar 2002 02:35:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26141 invoked from network); 14 Mar 2002 02:35:15 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 14 Mar 2002 02:35:15 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 13 Mar 2002 18:34:53 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g2E2ZE1S003726; Wed, 13 Mar 2002 18:35:14 -0800 (PST) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id SAA02562; Wed, 13 Mar 2002 18:35:13 -0800 (PST) To: zack@codesourcery.com cc: gdb@sources.redhat.com, gcc@sources.redhat.com Subject: Re: Suggestion: Detect inconsistent structure definitions References: <20020313182221.GE8197@codesourcery.com> From: cgd@broadcom.com Date: Wed, 13 Mar 2002 18:35:00 -0000 In-Reply-To: zack@codesourcery.com's message of "Wed, 13 Mar 2002 18:22:41 +0000 (UTC)" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 108ED3C74066073-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00125.txt.bz2 At Wed, 13 Mar 2002 18:22:41 +0000 (UTC), "Zack Weinberg" wrote: > Consider the following two source files: > > -- a.c -- > struct A { > int a; > int b; > }; > > struct A a = { 1, 2 }; > > -- b.c -- > struct A { > char a; > char b; > }; > > extern struct A a; > > int main(void) { > if (a.a == 1 && b.a == 2) > return 0; > else > return 1; > } > > -- > It is obvious that the complete program consisting of these two files > is buggy: the declarations of struct A do not match. However, the > program will compile, link, and execute with no complaints, just an > unexpected return value. > > When the program is large and complicated, this sort of bug can be > near-impossible to find, especially when the structure type > declaration _is_ properly isolated in a header file, but other headers > (possibly from third-party libraries) have issued inconsistent > typedefs/#defines for the aggregate's member types. I just spent two > days chasing exactly this problem in an INN installation. > > The compiler and linker do not have enough information to detect the > bug, but gdb does [ ... ] I believe that this type of bug will typically be discovered by proper application of 'lint'. There are open-source versions of lint out there... (I dunno what OSes ship them, but NetBSD definitely does.) If you want to solve this problem in the context of the gcc and related tools, my personal thought as to "the right thing" would be to create a mode for gcc which can output lint-like information instead of object code, and then create an external program to merge that information. (this is what lint does: in the first 'pass' it has a C parser, etc., and parses the C code and can output lint files (instead of .o files). then, another pass merges that all together and produces final results / warnings.) If you did the first pass inside GCC, you might even be able to do it so that it would even work/interoperate for languages other than C. 8-) chris