Re: Compiler support for preprocessors (was: Using noweb with sml)

Norman Ramsey <nr@cs.purdue.edu>
1 Mar 1996 13:56:06 -0500

          From comp.compilers

Related articles
Re: Compiler support for preprocessors (was: Using noweb with sml) nr@cs.purdue.edu (1996-02-23)
Re: Compiler support for preprocessors (was: Using noweb with sml) nr@cs.purdue.edu (Norman Ramsey) (1996-03-01)
| List of all articles for this month |

From: Norman Ramsey <nr@cs.purdue.edu>
Newsgroups: comp.compilers
Date: 1 Mar 1996 13:56:06 -0500
Organization: Department of Computer Science, Purdue University
References: <4gii2t$ovf@cantaloupe.srv.cs.cmu.edu> <4gvtk8$f5i@cantaloupe.srv.cs.cmu.edu>
Keywords: design, debug

Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
>About line-number pragmas, ...
>
>I've been thinking about that for a while, and the main problem is
>that line numbers don't mean much in Caml: all error reporting is done
>in terms of characters (positions of the first and last character of
>the offending sub-expression). This allows precise highlighting of
>the error location. Line numbers are also printed, but they are merely
>recomputed from the character positions.


This problem is tricky for a number of reasons---those contiguous
character positions may no longer span contiguous source locations
when projected back onto the original source. I got badly bitten by
this problem using a testing tool whose browser insisted that all
basic blocks occupied contiguous source locations. Even though it
supported C-style #line pragmas, the display was shot to hell.


>An easy way to handle the "#line" pragma is to take it into account
>only when converting character positions to line numbers + character
>offsets. However, this only works if the preprocessor is
>line-oriented, i.e. if it merely inserts or shuffles whole lines, but
>does not change the line structure. That may [not be the case for
>advanced preprocessing].


It is not even the case for the C macro processor. It is a pity,
since a little attention to detail in the preprocessor would make it
easy to preserve the original source coordinates in (file, line,
column) form, simply by inserting suitable white space ahead of the
tokens to keep them in their original columns. Unfortunately, the
only C preprocessor I know of that even attempts to preserve column
positions is integrated with a source-code instrumentation tool and
can't easily be teased out.


I have directed followups to comp.compilers.


Norman
--
Norman Ramsey
http://www.cs.purdue.edu/homes/nr
--


Post a followup to this message

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