Re: Identifying source file locations.

[Per Bothner <per at bothner dot com>]

kalmquist2@hotmail.com (Kenneth Almquist) writes:

> By "source order" do you mean sort by file name followed by line
> number within the file?  This leaves open the question of how to
> sort the file names.  The main issue here is that errors can
> cascade.  For example, if there is a syntax error in a declaration
> in a header file leaves a variable undefined, then a subsequent
> reference to that variable in another file will result in a second
> diagnostic.  We want the diagnostic on the declaration to come out
> first.

No strong feeling either way.  (It's not issue for Java!)

I do suggest having some provision for ranges.  How about:

struct source_location
{ /*  The field order is to facilitate better alignment. */
  int first_line : 24;
  int span_columns : 8;
  int first_column : 16;
  int span_lines : 16;
};

The end line (column) is first_line + span_lines - 1 (respectively
first_column + span_columns - 1).  If span_lines==0, then the ending
position is either unknown or meaningless or too large.  (If it
doesn't fit in 16 bits, it probably isn't very interesting.)

A complicated issue is how tabs should be counted.  The Unix
approach is to assume tabs are always 8 columns apart, and
so take that into account in the calculation.  However, I have
learned (or been told emphatically) that in the Windows world,
tab width is a matter of personal preference.  Most IDEs will
use tabs exclusively for indentation, and then its a user
perference setting how wide thus tabs should appear on the screen.
There is something to be said for that approach, but it is very
different from Unix tradition.  So we need to be aware of this.
Probably Gcc should be a user preference setting for how column
numbers should be calculated, so people can match it with their
editor etc.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/