Re: Hand-rolled parsers

chris@mimsy.umd.edu (Chris Torek)
12 Nov 89 05:34:36 GMT

          From comp.compilers

Related articles
Hand-rolled parsers firth@sei.cmu.edu (1989-11-09)
Re: Hand-rolled parsers bart@videovax.tv.tek.com (Bart Massey) (1989-11-10)
Re: Hand-rolled parsers chris@mimsy.umd.edu (1989-11-12)
Re: Hand-rolled parsers diamond@ws.sony.junet (1989-11-14)
| List of all articles for this month |

From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.compilers
Date: 12 Nov 89 05:34:36 GMT
References: <1989Nov10.025412.4014@esegue.segue.boston.ma.us>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

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





Post a followup to this message

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