Re: Suggestion: Detect inconsistent structure definitions

[cgd@broadcom.com]

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