This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH column number support


On Mon, Dec 01, 2003 at 11:02:58PM -0800, Per Bothner wrote:
> Obviously we can allocate line numbers completely
> densely by using a new line_map for each token, but the goal is
> to avoid allocating many more line_map entries that current.

Clearly such an extreme would not be wise, since it is very common
to increment the line number by one.  But I might guess that the 
average max column number is ~60 and not ~255.  Or entirely absent
if the front end in question doesn't track it.  Such details should
not be spread about.

Further, I might guess that once we start using line-map outside
of the parser we will no longer have monotonically increasing line
numbers.  We might well want to preserve map space and search for
an existing file+line number.

I'd like to have some check for exhausting map space.  This was
possible before with extraordinarily large inputs, but with the column
space now allocated, you've made it two orders of magnitude easier.  I
don't know if an abort is viable; forcing saturation at UINT_MAX and
letting that print as "<line number overflow>:0:0" sounds plausable.

What do we do if the user writes "#line 33554432"?  or 10000000000?
Does this differ between 32 and 64-bit hosts?


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]