Path: utzoo!attcan!uunet!samsung!think!ames!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!vector!chip From: chip@vector.Dallas.TX.US (Chip Rosenthal) Newsgroups: comp.unix.xenix Subject: compiler diagnostics [was Re: comp.unix.xenix] Keywords: cc error messages in SCO UNIX System V/386 r3.2 Message-ID: <1124@vector.Dallas.TX.US> Date: 26 Nov 89 16:11:49 GMT References: <529@s5.Morgan.COM> <69@van-bc.UUCP> <1989Nov25.204009.246@xenitec.on.ca> <1123@vector.Dallas.TX.US> <71@van-bc.UUCP> Reply-To: chip@vector.Dallas.TX.US (Chip Rosenthal) Organization: Dallas Semiconductor Lines: 68 In article <71@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes: >In article <1123@vector.Dallas.TX.US> chip@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@chinacat.Lonestar.ORG /// texbell!chinacat!chip ===> By the time you receive this, will be inactive. ===> Please send replies to .