Re: Suggestion: Detect inconsistent structure definitions

["Kris Warkentin" <kewarken at qnx dot com>]

Seems to me that the linker should be able to detect this problem as
well....It uses the debug information for error reporting.  The problem here
is not so much the definitions of the structures but the reference to a
variable defined in another object which has a different definition.
Perhaps some smart checking would only look at external references and see
if they have compatable definitions rather than just looking at definitions.
That being said, I'd love to see that myself - we have some defines that
cause things in our headers (particularily things like struct stat) to be 32
or 64 bit on some of it's fields.  That can wreak some serious havoc if your
lib and app are compiled with different flags.

cheers,

Kris
----- Original Message -----
From: "Zack Weinberg" <zack@codesourcery.com>
To: <gdb@sources.redhat.com>
Sent: Wednesday, March 13, 2002 1:22 PM
Subject: Suggestion: Detect inconsistent structure definitions


> 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
>
> $ strings -a a.out | grep '^A:'
> A:T(0,20)=s8a:(0,1),0,32;b:(0,1),32,32;;
> A:T(0,20)=s2a:(0,2),0,8;b:(0,2),8,8;;
>
> I can see the same thing in readelf -w output when DWARF2 is used,
> although more verbosely.
>
> It Would Be Nice if gdb would notice this and print a warning message,
> along the lines of
>
> warning: type `struct A' defined inconsistently in object files `a.o'
> and `b.o'
>
> when started up.
>
> zw
>