compiler diagnostics [was Re: comp.unix.xenix]

[Chip Rosenthal]

In article <71 at van-bc.UUCP> jtc at van-bc.UUCP (J.T. Conklin) writes:
>In article <1123 at vector.Dallas.TX.US> chip at chinacat.Lonestar.ORG (Chip Rosenthal) writes:
>>ccom: Error: foo.c, line 7: foobar undefined
>>          		(--( 	(&_iob[1]))->_cnt < 0 ?
>>_flsbuf((unsigned char) ((foobar)), ( 	(&_iob[1]))) :
>>(int) (*( 	(&_iob[1]))->_ptr++ = (unsigned char) ((foobar))));
>>      -----------------------------------------------------------------------
>>--------------------------------------------------------^
>
>I guess that's the price you have pay to have a separate pre-processor.
>If it was integrated to the compiler, perhaps the compiler could cashe
>the line and report the following:
>
>ccom: Error: foo.c, line 7: foobar undefined
>      putchar(foobar);
>      ----------^

Not really.  Certainly the compiler could get back to the line in the
original source file in which the error occurred, much pain is taken with
"#line" to maintain this information.  However, parsing is being performed
upon the cpp output, and correlating the token which caused the error
back to the original source file seems non-trivial.  The fact that
preprocessing is a seperate pass isn't really an issue.  The issue is
that the code available to the compiler at which time errors are detected
is not the same code that you wrote.

Two points follow from this.  First, given error message one:

    foo.c(7) : error 65: 'foobar' : undefined

and error message two:

    ccom: Error: foo.c, line 7: foobar undefined
	  putchar(foobar);
	  ----------^

Do you really think error message two will significantly improve your
programming productivity?

Second, given that sw manufacturers are only going to expend limited
resources on compiler designs, wouldn't you really prefer to see that
effort placed on better optimizations than this sort of thing?

>>Besides, be careful what you ask for.  You might get it.
>Although the one compiler I've used that repaired dumb mistakes did
>an admirable job,  I'm unsure of whether or not I'd want to use one today.

In my case, it was PL/C.  It made sense when we were running batch -- a
dropped semicolon meant a good 20-40 minutes to repunch cards and rerun
the job.  These days, at the cost of a 3 minute edit and recompile, I
don't think it's worth it.  Again, there are more important things which
can be done.

>I would be certain of that if every compiler had adequate diagnostics.
>If the choice is between terse diagnostics like Microsofts, or the
>potentially verbose diagnotistics like the MIPS compiler, I assure
>you I'd take verbosity.

This isn't a flame on verbose error messages.  But rather a plea to
make them |just good enuf| for me to figure out the bug, and then
spend the rest of the time on more important things.  For example,
I would much rather have the "inifinite spill" bug fixed rather than
a more verbose diagnostic saying more precicely where it is...

-- 
Chip Rosenthal  ///  chip at chinacat.Lonestar.ORG  ///  texbell!chinacat!chip
===> By the time you receive this, <chip at vector> will be inactive.
===> Please send replies to <chip at chinacat>.