This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggestion: Detect inconsistent structure definitions


On Wed, Mar 13, 2002 at 10:22:22AM -0800, 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; each object file's debug info will contain a type
> declaration for struct A, and they won't match.  With stabs, it's
> obvious just doing

It's not clear that GDB does.  Consider a slightly modified example:

> -- a.c --
> struct A {
>   int a;
>   int b;
> };
> 
> static struct A a = { 1, 2 };
> 
> -- b.c --
> struct A {
>   char a;
>   char b;
> };
> 
> static struct A a = {3, 4};
> 
> int main(void) { 
>   if (a.a == 1 && b.a == 2)
>     return 0;
>   else
>     return 1;
> }
> 
> --

OK, that's a somewhat degenerate case, but my point holds.  When do we
have enough information to know that two references are 'supposed' to
be of the same type, rather than an implementation-private type?  And in
stabs, at least, no debug information appears to be emitted for
'extern' statements, so we don't know if a file referenced the type it
had a different definition of or not.

Perhaps a command to show types with multiple different definitions? 
Please file a GNATS PR so that this idea doesn't get forgotten.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]