Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!lotus!esegue!compilers-sender
From: diamond@ws.sony.junet (Norman Diamond)
Newsgroups: comp.compilers
Subject: Re: Hand-rolled parsers
Message-ID: <1989Nov14.154322.9493@esegue.segue.boston.ma.us>
Date: 14 Nov 89 15:43:22 GMT
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: diamond@ws.sony.junet (Norman Diamond)
Organization: Compilers Central
Lines: 62
Approved: compilers@esegue.segue.boston.ma.us

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)
-- 
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.