Re: Hand-rolled parsers

diamond@ws.sony.junet (Norman Diamond)
Tue, 14 Nov 89 11:11:42 JST

          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 |

Date: Tue, 14 Nov 89 11:11:42 JST
From: diamond@ws.sony.junet (Norman Diamond)

In message <1989Nov12.222136.14085@esegue.segue.boston.ma.us>,
chris@mimsy.umd.edu (Chris Torek) complains about "fancy" error
reporting in the MIPS C compiler, a technique which is less helpful
than in non-preprocessed languages (lines broken at 72 characters):


>[begin quote]


"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++;


[...]


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.


>[end quote]


In fact I found this very helpful when errors were introduced by macros,
e.g. when there is a syntax error, or a call to what should be a nested
macro but which forgot to exist. (Dr. Torek mentioned this in an aside,
as a possibility. Please be assured that it is very very possible.)


Furthermore Dr. Torek's request is difficult to meet in systems that
separate preprocessing into a separate pass (I believe Dr. Torek might
know someone who worked on such a system :-)).


I think the best option is, if you don't like the echo of the processed
line and the mess of uncountable (well, not reliably countable) lines of
hyphens, then ignore this mess and only read the line number at the
beginning of the error message. Then you can still enjoy hunting on
your own through that original source line and the macro calls, as you
get to do in older systems.
--
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)





Post a followup to this message

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