Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!esegue!compilers-sender From: chris@mimsy.umd.edu (Chris Torek) Newsgroups: comp.compilers Subject: Re: Hand-rolled parsers Message-ID: <1989Nov12.222136.14085@esegue.segue.boston.ma.us> Date: 12 Nov 89 22:21:36 GMT References: <1989Nov10.025412.4014@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: chris@mimsy.umd.edu (Chris Torek) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 57 Approved: compilers@esegue.segue.boston.ma.us Speaking of error recovery and error messages: this brings up something which is a problem in some newer C compilers. Fancy error reporting is useful with, say, Pascal or Modula 2, where you might see something like this: "foo.p", line 12: missing `]' inserted var a : array[1..10 of integer; -------------------^ Unfortunately, when this is naively applied to C code, the result is often something like this (lines broken at 72 characters): "foo.c", line 12: missing `;' inserted (--((&__stdioF[1]))->_w < 0 ? ((&__stdioF[1]))->_w >= (( &__stdioF[1]))->_lbfsize ? (*((&__stdioF[1]))->_p = ((--((&__stdioF[0])) ->_r < 0 ? __stdio_rget((&__stdioF[0])) : (int)(*((&__stdioF[0]))->_p++) ))), *((&__stdioF[1]))->_p != '\n' ? (int)*((&__stdioF[1]))->_p++ : __st dio_wbuf('\n', (&__stdioF[1])) : __stdio_wbuf((int)((--((&__stdioF[0]))- >_r < 0 ? __stdio_rget((&__stdioF[0])) : (int)(*((&__stdioF[0]))->_p++)) ), (&__stdioF[1])) : (*((&__stdioF[1]))->_p = ((--((&__stdioF[0]))->_r < 0 ? __stdio_rget((&__stdioF[0])) : (int)(*((&__stdioF[0]))->_p++))), (i nt)*((&__stdioF[1]))->_p++)) chars++; -------------------------------------------------------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ ----------------------------^ Of course, the mess the compiler spat out above is nothing like the original line 12, which actually read putchar(getchar()) chars++; In practise, the errors I have seen have been even uglier than the one above, since there is actually more text, most of it blanks and tabs, which I compressed out of the above expansion. (Not to pick on them, but this particular bit of naive `friendly' error reporting is done by the MIPSco C compiler as shipped by DEC for Ultrix 3.x on the DECstation 3100. I have not seen anyone else actually commit this bit of stupidity. Friendly error reporting is all well and good, but at least this should be optional, so that it does not get in the way of integrated environments such as that provided by Emacs. Moreover, it should refer to the original source code, not any intermediate output. [It is possible that the error is only in the intermediate output, of course, as, e.g., with a bad `#define'.]) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.