Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!iuvax!watmath!xenitec!timk
From: timk@xenitec.on.ca (Tim Kuehn)
Newsgroups: comp.unix.xenix
Subject: Re: comp.unix.xenix
Keywords: cc error messages in SCO UNIX System V/386 r3.2
Message-ID: <1989Nov25.204009.246@xenitec.on.ca>
Date: 25 Nov 89 20:40:09 GMT
References: <529@s5.Morgan.COM> <69@van-bc.UUCP>
Reply-To: timk@xenitec.UUCP (Tim Kuehn)
Organization: XeniTec Consulting Services, Kitchener, ON, Canada
Lines: 67

In article <69@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes:
>In article <529@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
>I think that the lack of comprehensive diagnostics is the most serious
>drawback of the present SCO UNIX/XENIX C compilers.
>
>Given the compiler technology availiable today, there is absolutely
>no excuse for poor diagnostics.

Which is probably why Lint(CP) is included in with the development system. 
Although it doesn't display error messages as comperable to the one's you're
looking for (following), the docs state that it "attempts to detect features
of the C program <file> that are likely to be bugs, nonportable, or wasteful. 

>For example, I would expect the following code:
>
>    #include <stdio.h>
>
>    main(argc, argv)
>    {
>	printf("hello, world!\n")
>	printf("%d, %d\n", foo bar);
>    }
>
>
>to produce error messages similar to the following:
>
>    cc1: Warning: foo.c: line 5: Inserting Missing Semicolon
>	    printf("hello, world!\n")
>	 ----------------------------^

How would a compiler know that's supposed to be a semi-colon and not a 
math/string/pointer operator of some kind? 

>    cc1: Error:   foo.c: line 6: Undefined Identifier
>	    printf("%d, %d\n", foo bar);
>	 ----------------------^

Undefined, missing comma, or extra space? 

>    cc1: Warning: foo.c: line 6: Inserting Missing Comma
>	    printf("%d, %d\n", foo bar);
>	 -------------------------^

Missing comma, math/string/pointer operand or other? 

While what you ask for sounds *very* nice (and I'd love to have a C compiler
that'd do diagnostics like that!) it involves a level of intuiting what the 
programmer was trying to do, and I for one would rather the compiler just
tell me "this is what's wrong, and here's what's wrong with it." rather 
than just spitting out an error code I'd have to look up in a ref. manual 
somewhere. To have the compiler modify the code, or how the code behaves, 
particularly in the case of a error (ie unknown) condition is something that
I would *not* want. (How would you know what the compiler's really done with 
your code then?)

(I liked the HP 3000 compilers for that, if the error message wasn't clear 
enough, you could go to the manual, find the error number, and the manual 
would tell you more specifically what the error meant and suggest ways to 
correct the problem.)

+-----------------------------------------------------------------------------+
|Timothy D. Kuehn	       			       timk@xenitec.on.ca     |
|TDK Consulting Services			       !watmath!xenitec!timk  |
|871 Victoria St. North, Suite 217A					      |
|Kitchener, Ontario, Canada N2B 3S4 		       (519)-741-3623 	      |
|DOS/Xenix - SW/HW. uC, uP, DBMS. 		       Quality SW Guaranteed  |
+-----------------------------------------------------------------------------+