Re: A lesson for compiler warning writers

derek@knosof.uucp (Derek M Jones)
Mon, 22 Jun 1992 17:59:27 GMT

          From comp.compilers

Related articles
[11 earlier articles]
Re: A lesson for compiler warning writers hagerman@ece.cmu.edu (1992-06-19)
Re: A lesson for compiler warning writers igor!voltaire!davidm@uunet.UU.NET (1992-06-19)
Re: A lesson for compiler warning writers dww@inf.fu-berlin.de (1992-06-20)
Re: A lesson for compiler warning writers preston@dawn.cs.rice.edu (1992-06-21)
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-22)
Re: A lesson for compiler warning writers prener@watson.ibm.com (1992-06-22)
Re: A lesson for compiler warning writers derek@knosof.uucp (1992-06-22)
Re: A lesson for compiler warning writers kendall@centerline.com (1992-06-23)
Re: A lesson for compiler warning writers rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-06-23)
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: derek@knosof.uucp (Derek M Jones)
Keywords: C, lint
Organization: Compilers Central
Date: Mon, 22 Jun 1992 17:59:27 GMT

>maniattb@cs.rpi.edu (Bill Maniatty) writes:
>I have said this before, in different forums, but perhaps not as clearly.
>Rigorous compiler checking is a Good Thing, but it is not enough. No C
>compiler in the world will do cross file checking for you, only lint does


Our compiler does full cross checking (well actually it
generates the info needed by our linker to do the job).


> file a.c:
>
> double foo(long a) { return a * 2.0 ; }
>
> file b.c
>
> #include <stdio.h>
> extern short foo(double a);
> int main(void) { printf("%d\n", foo(1.0)); return 0; }
>[the compiler and linker won't catch this]
>
>[I've always wondered how hard it would be to have a declarations database
>that compilers could consult and update as they compiled stuff. That must
>be a standard CASE thing. -John]


We sometimes call our intermediate code files a database. But this
terminology is more of an after thought.


For those of you into this sort of thing the following are good tests
of how well a cross module checker does it's job:


file 1: enum {a,b,c} x; file 2: enum {c=2, b=1, a=0} x;


the x's are compatible.


file 1: enum {a,b,c} x; file 2: enum {c=2, b=1, a=3} x;


the x's are not compatible (cross translation rules allow mixed
orderings but values must be the same).


file 1: int f(int); file 2: int f();


f's are compatible.


file 1: int f(char); file 2: int f();


f's are not compatible.


The rules that need to be followed when there are/aren't
prototypes in some modules and calls with out prototypes
are very complicated. So I will not give an example.


Also struct compatibility is by structure, not name. So what
about:


file 1:


struct s1{struct s2 *f1;} x;
struct s2{struct s1 *f1;};


file 2:


struct s1{struct s2 *f1;}x;
struct s2{struct s3 *f1;};
struct s3{struct s1 *f1;};


Are the x's compatible? Hint. You will need to refer to some recent
X3J11 interpretation answers.


derek jones
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.